Build an integration that respects account permissions
Choose the endpoint by the action
An API integration should begin with a narrow business requirement. A publisher checking a tracking link needs a different operation from an advertiser reviewing campaign performance. Locate the appropriate endpoint group above, identify which account owns the requested record and decide what your service will do with the response.
Avoid treating a successful login as permission to read every object on the platform. Scope is part of the request contract, and an identifier copied from another account does not establish access. Start with a read operation in an account you control before introducing changes to campaign or financial records.
Keep authentication on the intended boundary
Use the authentication method documented for the selected endpoint. The account token shown in this reference and a server integration key serve different entry points; putting one credential into an unrelated header will not make it interchangeable. Store credentials outside public source files and pass them only to the intended ADJODO host over HTTPS.
A browser address is a poor place for a secret because it can be retained in history or shared with the link. When diagnosing an authentication failure, check the header name, active account and endpoint requirements before creating additional credentials.
Handle responses as structured decisions
A JSON response can represent success, a validation problem or a denied operation. Inspect the HTTP status before reading fields that belong only to successful responses. Show a useful error near the operation that failed, preserve the user's editable input and avoid displaying raw credential values in support messages.
For list endpoints, follow the response structure rather than assuming every result fits into a single screen. Missing optional values should remain missing instead of becoming invented defaults. A performance figure, wallet amount or campaign state needs its accompanying meaning to stay useful outside the dashboard.
Make retries deliberate
Network failures do not always tell you whether the server received a request. Retrying a read is different from repeating a submission that might create a record. For conversion postbacks, keep the conversion identifier stable when sending the same event again; changing it would describe another event rather than a retry.
Record enough context to reconcile the attempt without storing unnecessary customer data. Back off after repeated failures and investigate validation errors instead of resending unchanged input indefinitely. Where an endpoint supports a request identifier, follow that endpoint's documented rules rather than assuming one universal retry mechanism.
Verify the complete path before release
An integration is ready when the intended user action produces the correct owned record and the receiving system can explain the result. Test an accepted request, a malformed request, a missing credential and an account that lacks access. Confirm that your interface distinguishes an empty list from a failed request.
For webhooks, check the configured HTTPS destination and the signature verification procedure before accepting messages as trusted events. Keep a short integration note describing the endpoint, account role, expected fields and recovery steps. That note gives the next maintainer a clear starting point when settings or campaign requirements change.