Skip to main content
aditya.mandavi
aditya.mandavi
Participating Frequently
January 27, 2026
Question

PUT Form Fields API is not working consistently

  • January 27, 2026
  • 1 reply
  • 115 views

We are building an Adobe Sign integration in our application for our customers.

We use Adobe Sign REST APIs to create and send agreements with dynamic signature positions provided by our users. To implement this, we followed the approach described in the article below:
https://helpx.adobe.com/sign/kb/formfields-option-is-not-available-in-v6-of-rest-api-adobe-sign.html


Current implementation flow: 
Based on above, we are following below steps in our application now to send agreements.

  1. Create the agreement in AUTHORING state using POST /agreement.
  2. Get all members (to get participant set IDs) using GET /agreement/{{agreement-id}}/members.
  3. Call PUT /agreement/{{agreement-id}}/formFields to update signature positions on the document.
  4. If PUT /agreement/{{agreement-id}}/formFields (step # 3) fails, wait for 1 second and then retry step # 3. We repeat this until the call succeeds or the maximum retry limit (5 attempts) is reached.
    Note: The wait and retry logic was added based on guidance from the discussion thread we had started on older Adobe Sign community thread. The discussion thread in older community forum is no more accessible.

Once above is completed, the document moves to OUT_FOR_SIGNATURE as suggested on the discussion thread in older community forum.

Issue we are facing currently:
With above logic implemented, we are finding a intermittent (but frequent) issue:
 - The PUT /agreement/{{agreement-id}}/formFields call returns success within the maximum retry attempts.
 - But, when we open the document sent to signer, the signature block is not present.
 - When we subsequently call
GET /agreement/{agreement-id}/formFields, the response shows that the form fields do not match those sent in, or returned from, PUT /agreement/{agreement-id}/formFields.

I am attaching
(1) a sample document we are using.
(2) JSON request for POST /agreement.
(3) JSON request for PUT /agreement/{{agreement-id}}/formFields.
(4) JSON response for PUT /agreement/{{agreement-id}}/formFields.
(5) JSON response for GET /agreement/{{agreement-id}}/formFields.

Could you please help us understand what could be the issue?

    1 reply

    aditya.mandavi
    aditya.mandaviAuthor
    Participating Frequently
    January 28, 2026

    Hi ​@S_S,

    The thread in older community forum is not accessible anymore.

    Could you please help us here with the above intermittent issue we are facing?

    Thanks,

    Aditya

    S_S
    Community Manager
    S_SCommunity Manager
    Community Manager
    January 28, 2026

    Hi ​@aditya.mandavi,

     

    Note: All posts, replies, solutions, feature requests, and bug reports created on or before November 16 are already available. Content created between November 17 and launch day will be added soon—no data will be lost, and you won’t need to recreate anything.

    More info here: 

     

    Thanks for tagging me. 

    Your POST /agreements request is correct and valid. Key confirmations from 2-post-agreement.json: 

    • Agreement is created in “state”: “AUTHORING”

    • Single signer, correct role 

    • Document is provided via URL 

    From 4-put-form-fields-response.json, Adobe Sign accepts the form field definition:

    • Field is created

    • Field is associated to the correct signer

    • Coordinates are accepted

    • Response payload confirms the field exists

     

    Now, let’s understand the issues:

     

    From 1-sample-pdf-document, the document has these critical characteristics:

    • Generated by Aspose.Words

    • Contains watermark text, external hyperlink overlays, flattened text objects

    • No AcroForm fields

    • No predictable text flow

    This matters because Acrobat Sign normalizes the PDF internally before placing fields.

    Aspose-generated PDFs commonly have:

    • MediaBox ≠ BleedBox

    • Sometimes, TrimBox or BleedBox present

    • Text and link overlays positioned relative to one box

    • Adobe Sign placing fields relative to another

    This explains why:

    • PUT /formFields sometimes works

    • Sometimes fields appear offset

    • Sometimes fields seem to “disappear”

    • Sometimes GET /formFields shows them, but UI placement looks wrong

    This is not a timing issue in your case.

     

    From 5-get-form-fields.json:

    • Adobe Sign detects link objects and converts them into internal fields 

    • These overlays overlap the same region as your signature placement

      5-get-form-fields

    That overlap causes Z-order conflicts, field rendering inconsistencies, and occasional UI suppression of the signature block. This is critical.

     

    That being said, before sending the PDF to Acrobat Sign:

    1. Open the PDF in Acrobat

    2. Go to Print Production

    3. Run Preflight

    4. Apply:

      • “Fix page boxes”

      • Set CropBox = MediaBox

    5. Save the PDF

    6. Upload that PDF to Acrobat Sign

    This removes the coordinate ambiguity.

     

    Let us know if this works for you.

     

    Regards,

    Souvik

    aditya.mandavi
    aditya.mandaviAuthor
    Participating Frequently
    January 29, 2026

    Hi ​@S_S 

    One clarification on above.

    I think there is NO overlap in these two locations.
    i.e. signature is placed at (3-put-form-fields-request)
    ​​​​​​

                        "left": 258.66,
                        "top": 567.62,
                        "width": 112,
                        "height": 24

    and the Aspose links appear at (5-get-form-fields)
    ​​​​​

                        "top": 704.796,
                        "left": 201.621,
                        "width": 253.59399999999997,
                        "height": 14.520000000000095


    Is the issue (Z-order conflicts) expected to occur only when there is an overlap? If yes, why it might be happening in our case where there is no overlap?

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices