Push URL Callback

The Push URL callback is how your backend receives saved email content after an End User saves in the editor.

Configure a Push URL before production use. The editor does not return final email HTML through iframe state, browser state, or Return URL. Your backend should treat the Push URL callback as the source of saved email content.

Configure Push URL

Open:

Application -> Editor API -> Push URL

Enter an HTTPS endpoint from your backend.

Example:

https://api.yourproduct.com/webhooks/asc-editor-save

Your endpoint must:

Accept POST requests.
Read the encrypted request body.
Decrypt the payload according to your Application configuration.
Store the saved email content.
Return HTTP 200 after successful processing.

Push Key

The Push Key is used by your backend to process encrypted callback requests.

Keep the Push Key on your backend only. Do not expose it in frontend code, mobile apps, logs, or public repositories.

If you reset the Push Key in the Console, update your backend before relying on new save callbacks.

Request format

When encrypted callback delivery is enabled, the Editor plugin sends:

POST {Push URL}
Authorization: <KEY>
Content-Type: text/plain

<DATA>

Part	Description
`{Push URL}`	The HTTPS callback endpoint configured in your Application.
`Authorization`	Encrypted key value `KEY`. Your backend uses the Push Key to decrypt it.
Request body	Encrypted email content `DATA`.

Encrypted callback flow

flowchart TB
    subgraph ASC["Editor plugin"]
        direction TB
        A1["1. Generate<br/>symmetric key S"]
        A2["2. Encrypt saved email content<br/>with symmetric key S<br/>DATA = encrypted content"]
        A3["3. Encrypt symmetric key S<br/>KEY = encrypted S"]
        A4["4. Send callback request<br/>POST {Push URL}<br/>Authorization: KEY<br/>Body: DATA"]
        A1 --> A2
        A2 --> A3
        A3 --> A4
    end

    subgraph Customer["Your backend"]
        direction TB
        B1["5. Push URL<br/>receives request"]
        B2["6. Use Push Key<br/>to decrypt KEY<br/>and recover S"]
        B3["7. Use S<br/>to decrypt DATA<br/>and recover email content"]
        B4["8. Store<br/>email content"]
        B5["9. Return<br/>HTTP 200"]
        B1 --> B2
        B2 --> B3
        B3 --> B4
        B4 --> B5
    end

    A4 --> B1

Decrypted payload

After decryption, the payload contains saved email content and metadata.

Example:

{
  "emailId": 123,
  "userId": "user_12345",
  "name": "Welcome Email",
  "subject": "Welcome to our platform",
  "html": "<!DOCTYPE html><html><body>Welcome</body></html>",
  "settings": "{\"body\":{\"rows\":[]}}",
  "timestamp": 1781058600
}

Confirm the final payload field names and encryption details for your Application before production launch.

Expected response

Return HTTP 200 only after your backend has accepted and stored the content.

Example:

HTTP/1.1 200 OK
Content-Type: text/plain

OK

The Editor plugin does not retry failed pushes. If your endpoint returns a non-200 response or times out, your backend may not receive that saved version again.

Processing recommendations

Your Push URL endpoint should:

Verify the request format before processing.
Decrypt KEY and DATA on your backend.
Store the latest HTML and editor settings.
Handle repeated saves safely.
Return HTTP 200 only after successful processing.
Log failed decryptions and storage failures for debugging.

Idempotency

End Users may save the same email multiple times.

Design your endpoint to process repeated callbacks safely. Use fields such as emailId, userId, and timestamp to decide whether an incoming callback is new, duplicate, or older than content you already stored.

Testing

Before production use:

Configure the Push URL.
Store the Push Key securely on your backend.
Open the editor with a test End User.
Save an email.
Confirm your endpoint receives KEY and DATA.
Confirm your backend decrypts and stores the returned content.
Confirm your endpoint returns HTTP 200.