# Client access delay for asynchronous order finalization

**URL:** <https://community.letsencrypt.org/t/client-access-delay-for-asynchronous-order-finalization/195950>\
**Category:** Client dev\
**Created:** [April 6, 2023, 5:24am UTC](https://community.letsencrypt.org/t/client-access-delay-for-asynchronous-order-finalization/195950 "2023-04-06T05:24:07Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![bruncsak](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bruncsak/32/18414_2.png) [@bruncsak](https://community.letsencrypt.org/u/bruncsak)\
**Post date:** [April 6, 2023, 5:24am UTC](https://community.letsencrypt.org/t/client-access-delay-for-asynchronous-order-finalization/195950/1 "2023-04-06T05:24:07Z")

</div>

> [@myVesta / HestiaCP / VestaCP: fail issuance with async finalization](https://community.letsencrypt.org/t/myvesta-hestiacp-vestacp-fail-issuance-with-async-finalization/195923/2):
>
> In between finalize and downloading the issued certifcate, that client needs to poll the order URL (_ **with exponential backoff, please!** _) until the "certificate" field appears in the Order object.

(Highlighting from me.)

Instead of the suggested exponential backoff, is the `Retry-after` header field supported for the `ACME` clients? At the end of the day, only the `ACME` server knows its own load level.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [May 6, 2023, 5:25am UTC](https://community.letsencrypt.org/t/client-access-delay-for-asynchronous-order-finalization/195950/2 "2023-05-06T05:25:02Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.