Support and diagnostics

For integration or API issues, open the current Application → Developer integration → Support and feedback to submit technical feedback, link diagnostics, read the timeline and reply. Explicitly forward a ticket when platform assistance is needed; existing private feedback is never forwarded automatically. Use the relevant product channels for commercial, payment or customer support.

Submit application technical feedback

1. Check the Application and environment, then enter a short subject and plain-text issue description.
2. Optionally select a diagnostic from call logs or a Webhook delivery from the last seven days. References include necessary summaries without request or customer bodies.
3. Submit explicitly and retain the ticket reference. Open its timeline for messages and status; read a message body only when needed.

Bodies must not include credentials, sensitive headers, JWTs or HTML. Directory access, body access and actions are authorized separately: a visible ticket reference does not grant permission to read or reply. Contact the current Application owner when required access is absent.

Forward to platform support

1. Select Forward to platform support on the current ticket and review the confirmation.
2. If requested, complete sensitive-action verification within the last five minutes. Return and confirm forwarding explicitly.
3. Check the forwarding entry in the timeline. Platform replies and status can subsequently be read in the original Application ticket.

The destination is fixed; no support account or target enterprise input is needed. Unforwarded feedback stays private. Closed tickets cannot be forwarded directly. Successful forwarding does not mean a reply or resolution, or guarantee immediate handling.

Verification, cancellation, rereading or log selection never automatically forwards, creates or replies to a ticket. While an outcome is unknown, the current page locks editing and returning to the list, and retains the original content, ticket revision and operation identifier. A sign-in or verification requirement during recovery does not prove the first submission failed. After the same user verifies, the page checks current Application access and ticket state before you explicitly select Retry original request. Read the latest timeline after a revision conflict and confirm again. An expired sign-in hides previously read message bodies; read them explicitly again after recovery. Changing the user, Application or enterprise clears the previous scope's content.

Reply and track status

Reply in the ticket timeline or update its state through the currently available actions. open, pending, resolved and closed describe the current ticket. Configuration or payment success does not automatically resolve an issue.

Situation	Action
Recent verification is required	Verify, return to the ticket and submit explicitly; no automatic replay
Creation, reply, status update or forwarding is unknown	Recover the original content and operation identifier
Ticket revision changed	Read the latest timeline, review and confirm again
Body access is denied or access revoked	Stop the old-scope operation and contact the Application owner
Reads are temporarily unavailable	Retry reads; do not display failure as no feedback or resolution

Issue details

• Application ID and environment;
• request_id or correlation_id;
• related operation_id, delivery_id, or event_id;
• UTC timestamp and affected endpoint or event type;
• HTTP status and machine-readable error code;
• minimal reproduction steps, expected result, and actual result.

Sensitive information

Remove the following information before submitting a request:

• client secrets, private keys, access tokens, or refresh tokens;
• webhook secrets or complete Authorization headers;
• customer data unrelated to diagnosis;
• database or internal account credentials.

Check before escalation

1. Confirm the environment and issuer.
2. Check token expiry, audience, and scopes without sharing the token.
3. Reuse the original Idempotency-Key for the same command.
4. Query the operation and current resource state.
5. For webhooks, check signature verification, Inbox persistence, deduplication, and version gaps.

Third-party diagnostics do not require platform-internal access.

Related guides: Call logs and quality · Error handling · Event reception