API, Automation & MCP Terms

1. Scope

1.1 These terms apply whenever the Services are used by automated means for a Customer: through an application programming interface, by script or integration, by browser automation, by an AI or large-language-model agent, or by a client that uses the Model Context Protocol (MCP) or a similar tool protocol ("Automated Access").

1.2 These terms supplement the role terms the Customer accepted (Advertiser Terms and/or Publisher & Supply Terms), the Advertising & Traffic Policy, the Payments, Refunds & Adjustments document and the Data Protection Terms. If they conflict: an Order Form prevails; the Data Protection Terms prevail on Personal Data; the role terms prevail on everything else, except where these terms deal specifically with Automated Access.

1.3 Automated Access is a way of using an existing Account. It does not create a separate contract, a separate Account or a separate Customer.

1.4 Admeking provides programmatic interfaces to the Account (the "API"). We state in the cabinet or in our documentation which interfaces are documented as stable. Interfaces that are not documented as stable, including the endpoints the cabinet web application itself calls, are made available as they are and may change or be withdrawn under clause 12.3.

2. Definitions

These definitions add to the Definitions document (DEFS) and do not change it.

2.1 Automated Client: any software that sends requests to the Services for a Customer, including scripts, integrations, AI agents and MCP clients. An Automated Client that a Customer authorises is a Customer Agent.

2.2 Credentials: passwords, session tokens, API keys, access tokens, postback keys and any other secret that authenticates requests for an Account.

2.3 Write Request: a request that changes the state of an Account, for example creating, changing, starting, pausing or archiving a Campaign, changing a bid or budget, creating a payment instruction, or changing Account settings.

2.4 Accepted Request: a request that our systems confirm, in their response, as received and accepted for processing.

2.5 Our Automation: the automated systems we operate for our own purposes in providing the Services, such as auction and bidding logic, pacing, budget control, Invalid Traffic filtering, review tools and reporting.

2.6 Managed Automation: automated or staff-operated changes that we make to a Customer's Account on its behalf, within a scope agreed under section 10.

3. One Customer, one contract

3.1 Every request made with an Account's Credentials, or by the Customer's Customer Agents, is made for the Customer that holds the Account, in the role it accepted, and under the version of the documents that the Customer accepted and that applies to the Account at the time of the request.

3.2 An Automated Client is a tool, not a party. It cannot accept terms in its own name, hold an Account or become a Customer. Acceptances, declarations and instructions given through Automated Access by a person or tool the Customer authorised are the Customer's own. The Customer confirms that each Customer Agent it lets act for it has the authority it uses.

3.3 Automated Access does not bypass acceptance. An Account may be opened, and Automated Access used, only after the Customer has accepted the documents required for its role. Where the API allows an Account to be opened, the request must carry an affirmative acceptance given by, or with the authority of, a person entitled to bind the Customer; a request without it is refused. We may refuse Automated Access, or limit it to reading, for an Account whose required acceptance is missing or out of date until the current version has been accepted.

3.4 Campaigns created or changed through Automated Access go through the same Campaign Declaration, review, moderation and policy checks as Campaigns created in the cabinet user interface. A material change made by an Automated Client (as defined in the Advertiser Terms, for example a change of product, category, payment terms, Destination or targeted countries) needs the same new declaration and review as a change made by hand. Changes must not be split, timed or automated in order to avoid review.

3.5 Information an Automated Client submits, such as Campaign Declarations, company details and URLs, is information the Customer gives us. It must be true and complete. An error by an AI agent or other Automated Client does not excuse an inaccurate declaration.

4. Customer responsibility for its agents

4.1 The Customer decides which Customer Agents and Automated Clients may act on its Account and what they may do. The Customer is responsible for their acts and omissions within the authority it gave them as for its own. This includes acts the Customer did not foresee but that fall within the access it granted, for example a budget increase made by an AI agent that had write access.

4.2 The Customer is responsible for the configuration, prompts, instructions and safeguards of its Automated Clients, for any third-party AI service, tool or MCP server it connects, for the data it lets them read and pass on, and for checking their output before relying on it.

4.3 Spending authority. An Automated Client with write access to Campaigns can commit Account Balance: it can create and start Campaigns and change bids and budgets. The Customer should give write access only to clients it trusts with that authority. Where the Services allow access to be limited (for example to reading, to certain Campaigns or to a spending limit), the Customer should use those controls. Where they do not, the Customer should limit the authority inside its own client, for example by requiring a person to approve budget increases above a threshold the Customer sets. Budgets set through Automated Access work as described in the Advertiser Terms and the Payments, Refunds & Adjustments document; a budget is not a hard spending cap unless those documents say so.

4.4 Unauthorised use. The Customer is responsible for requests made with its Credentials, except where:

(a) the request was made after the Customer notified us of a compromise under clause 6.4 and we had a reasonable opportunity to block the Credentials; or

(b) the misuse resulted from our breach of our own security obligations or from our own error.

Where mandatory law allocates responsibility for unauthorised use differently, that allocation applies.

4.5 We may treat an Accepted Request that is authenticated with valid Credentials of an Account as authorised by the Customer. We do not have to verify which person or tool sent it, but we act on credible signs of compromise that come to our attention (clause 6.4).

5. Our own automation and our own errors

5.1 Decisions and outputs of Our Automation are our acts. They are not instructions from the Customer.

5.2 Errors of Our Automation, and changes made under Managed Automation outside the agreed scope or limits, are our errors. They are handled under the correction, adjustment and liability provisions of the role terms and the Payments, Refunds & Adjustments document. They are not charged to the Customer as if the Customer had made them.

5.3 If our systems process a valid request incorrectly, for example by applying it to the wrong Campaign, applying a different value, or reporting as accepted a request that we did not apply, that is our error even though an Automated Client sent the request.

5.4 A request that our systems processed as it was sent remains the Customer's, even if its Automated Client sent it by mistake.

5.5 Nothing in these terms limits our liability where the law does not allow it to be limited. The liability provisions of the role terms apply.

6. Credentials and security

6.1 Credentials. We issue or accept the Credentials that the Services provide for an Account. Where the Services provide separate Credentials for Automated Clients, or Credentials limited to certain scopes (for example read-only access, access to certain Campaigns, or a spending limit), the Customer should use them instead of sharing a person's sign-in.

6.2 Keeping Credentials safe. The Customer must:

(a) keep Credentials confidential and give them only to Customer Agents that need them;

(b) not put Credentials in URLs (except where a feature is designed that way, such as a postback URL), in client-side code, public repositories, tickets, screenshots, or prompts and chat histories that third parties can read;

(c) store Credentials in a secrets store or an equivalent protected place;

(d) connect only to our published HTTPS endpoints; and

(e) give each Automated Client no more access than it needs, using limited scopes where the Services provide them.

6.3 No logging of secrets. The Customer must configure its Automated Clients, proxies and AI tooling so that they do not write Credentials into logs, traces, prompts, transcripts or error reports. We take reasonable steps to keep Credential values out of our own logs. We never ask for Credentials by email, chat or support ticket, and the Customer must not send them that way. If we find a Credential value recorded where it should not be, we remove it and, where the Services allow, rotate or invalidate the Credential, and tell the Customer if it needs to act.

6.4 Compromise notice. If the Customer knows or suspects that a Credential has been disclosed, misused or exposed to an unauthorised person or tool (including through a compromised AI agent or MCP server), it must without undue delay:

(a) notify us at [email protected], stating the Account, the Credential concerned, when the exposure happened as far as known, and which actions may be unauthorised;

(b) change or revoke the affected Credentials where it can; and

(c) stop the affected Automated Client.

After receiving the notice we block or invalidate the affected Credentials, or suspend access to the Account, as soon as reasonably practicable. A block takes some time to take effect in all systems; we do not promise an immediate block. We may take the same steps on our own initiative where we see signs of compromise.

6.5 Revocation and rotation. The Customer can change its password and, where the Services provide it, revoke sessions, keys or tokens and issue new ones. Where the Customer cannot revoke a Credential itself, it can ask us to do so at [email protected]. We may rotate or invalidate Credentials for security reasons, for example after a suspected compromise or when we change our signing keys. This can sign users out and require Automated Clients to be set up again. We give notice where practicable; security rotations can take effect immediately.

6.6 Customer systems. The Customer keeps the systems that run its Automated Clients reasonably secure, in particular those that hold Credentials with write access.

6.7 Our systems. We protect the Services and the Credentials we store with measures appropriate to the risk, as described in the Privacy Notice and the Data Protection Terms. We do not claim any security certification.

7. Rate limits and fair use

7.1 We may set limits on the number, frequency, size and concurrency of requests, on the number of objects per Account (for example Campaigns or open payment requests) and on sign-in attempts. Where we publish limits, the Customer must stay within them.

7.2 We may slow down, delay or refuse requests that exceed a limit or that put the stability of the Services at risk, including by returning an error that asks the client to try again later. Automated Clients must back off and retry with increasing delays.

7.3 The Customer must not get around limits, for example by using several Accounts, rotating IP addresses or Credentials, or spreading requests across Customer Agents.

7.4 We may change limits. We give notice of a material reduction of a published limit where practicable, except where an immediate change is needed to protect the Services.

8. Requests, results and charges

8.1 Accepted is not delivered. An Accepted Request means that our systems accepted the request for processing as stated in the response. It does not mean that a Campaign will deliver, that a Billable Event has or has not occurred, or that a payment has been received.

8.2 Charges come from serving. Billable Events and charges arise from serving recorded by our systems, as described in the role terms and the Payments, Refunds & Adjustments document, not from API responses. A request to pause or stop a Campaign, or to lower a bid or budget, takes effect once it has reached our serving systems. Billable Events recorded before then remain chargeable as those documents describe.

8.3 Timeouts and unclear results. If a request times out, the connection fails or the response is unclear, the request may or may not have been applied. The Customer must not assume that nothing happened. Before repeating a Write Request, the Customer should read the current state of the object concerned (for example the Campaign, its budget or the payment request) and repeat the request only if the change is not there. Repeated Write Requests can create duplicates, such as duplicate Campaigns or several payment requests. Duplicates are the Customer's responsibility unless they result from our error under clause 5.3.

8.4 Idempotency and receipts. Where the Services support idempotency keys, request identifiers or receipts for a Write Request, the Customer should use them. Repeated requests with the same idempotency key are then treated as one request for the period we state. Where these features are not supported, the Customer relies on reading the current state under clause 8.3. A receipt records what we accepted; the Statistics remain the basis for charges.

8.5 Payments. A request that creates a payment instruction, such as a deposit request with an amount to pay, does not move money. Account Balance is credited only when we have received and matched the payment as described in the Payments, Refunds & Adjustments document. The Customer must follow the instruction exactly, including the exact amount, and must check the status of a payment request before sending a payment again after a timeout.

8.6 Statistics read by automation. Statistics delivered through Automated Access are preliminary until they become final under the Payments, Refunds & Adjustments document, and they can lag behind serving. Automation must not treat preliminary Statistics as final figures or as proof of a billing error.

8.7 Postbacks. Where the Services accept server-to-server conversion reports (postbacks) authenticated by a postback key, the Customer is responsible for every report sent with its key. A postback key travels in a URL, so the Customer should expect it to appear in the logs of systems that handle that URL and should ask us to replace it, where the Services allow, if it is exposed. Conversion reports that do not reflect genuine conversions are Invalid Traffic.

9. AI agents, MCP and third-party tools

9.1 The Customer may use AI agents and MCP clients to operate its Account within these terms. It chooses them and is responsible for them, including compliance with their providers' terms.

9.2 No guarantee from AI output. Output from AI tools, whether the Customer's, a third party's or an AI-assisted feature we provide, is not legal advice, not policy approval and not a guarantee of compliance, delivery, conversions or return on spend. This covers, for example, suggested targeting, bids, ad copy, landing-page text and policy assessments. The Customer remains responsible for the Ads, Destinations, Campaign Declarations and settings it submits, however they were produced. Our review covers the submission we reviewed, as described in the Advertiser Terms.

9.3 Where we provide AI-assisted features, we say so where the feature is offered. Their output is a suggestion until the Customer applies it. This clause does not shift to the Customer responsibility for content that we create and serve on our own initiative, and does not limit our liability where the law does not allow it to be limited.

9.4 Untrusted content. An AI agent that reads web pages, emails, reports or other outside content can be manipulated by instructions hidden in that content. The Customer should configure agents with write access so that such content cannot trigger Write Requests without its own safeguards, for example human approval for budget increases, new Destinations and payment requests.

9.5 Data passed to tools. The Customer decides which Account data, Statistics and Personal Data it passes to AI providers and MCP servers. That is the Customer's own disclosure. It must have a lawful basis for it under the Data Protection Terms and must respect its confidentiality obligations. We are not responsible for how a third-party tool that the Customer chose processes data the Customer sent to it.

9.6 If we offer an MCP server or a similar connector, it is part of the Services. It acts on an Account only with Credentials the Customer provides and only within the access those Credentials carry, and its description states what it can do.

10. Managed Automation and changes made by our staff

10.1 We operate Managed Automation only where it has been agreed, either in an Order Form or in an instruction from the Customer that we confirm in writing (email or the cabinet is enough). Otherwise we do not operate the Customer's Account on its behalf. Actions we take under the role terms or our policies, such as review, suspension, correction and enforcement, are our own acts and not Managed Automation.

10.2 The agreement states:

(a) the Accounts and Campaigns covered;

(b) the actions allowed, for example bid changes within a range, pausing placements or moving budget between Campaigns;

(c) the spending limits, such as maximum daily and total spend and maximum bid;

(d) how long it runs;

(e) how the Customer approves anything outside the scope; and

(f) how the Customer withdraws.

10.3 Changes we make within the scope and limits are made on the Customer's behalf, and the Billable Events that result from them are chargeable. Changes outside the scope or above the limits are our error under clause 5.2.

10.4 The Customer remains responsible for its Ads, Destinations and Campaign Declarations and for the information and instructions it gives us. Managed Automation does not include a guarantee of results.

10.5 The Customer may narrow or withdraw Managed Automation at any time in writing. The change takes effect once we have had reasonable time to act on it and it has reached our serving systems.

10.6 When our staff change a Campaign at the Customer's request, for example its bid or budget, that change is treated as Managed Automation with the request as its scope. We keep a record of who made the change and when.

11. Restrictions and suspension of Automated Access

11.1 Automated Access must not be used to:

(a) access data of other customers or Accounts;

(b) probe, scan or test the security of the Services without our written permission (security findings can be reported to [email protected]);

(c) collect data from the Services beyond what the Account needs;

(d) interfere with or overload the Services;

(e) get around review, acceptance, moderation, limits or a suspension, including by opening Accounts to evade a block;

(f) generate Invalid Traffic, false Billable Events or false conversion reports;

(g) open Accounts in bulk, or resell or sublicense access to the Services; or

(h) misstate who the Customer is or who the actual advertiser is.

11.2 We may slow down, limit to reading, suspend or revoke Automated Access, or individual Credentials, where:

(a) these terms are breached;

(b) there is a security risk or a suspected compromise;

(c) the stability of the Services is at risk;

(d) the law or an authority requires it; or

(e) it is needed to stop a serious violation of the role terms or the Advertising & Traffic Policy.

We choose the least restrictive measure that is adequate. Where that is enough, we restrict only Automated Access and not the whole Account.

11.3 We tell the Customer which measure we took and why, where this is practicable and lawful: before the measure, or promptly after it where immediate action was needed. We do not disclose detection details that would help someone get around our controls. We lift the measure when its reason has ended. The Customer may contest the measure through its usual support contact.

11.4 A restriction of Automated Access does not change amounts already owed or any right to a refund of Account Balance under the Payments, Refunds & Adjustments document.

12. Changes to the API and deprecation

12.1 We may develop Automated Access features. Additive changes, such as new fields, endpoints, optional parameters or error codes, can be made at any time. Automated Clients must tolerate them.

12.2 For a change that breaks an interface documented as stable, we give at least 30 days' notice through the cabinet, by email or in our documentation, and we name the date on which the old behaviour ends.

12.3 We may make changes with shorter or no notice where they are needed for security, by law or by an order of an authority, because of a change by a third-party platform outside our control, or where the interface is not documented as stable, including beta features and the internal endpoints of the cabinet web application. We tell Customers affected as soon as practicable.

12.4 Changes to these terms follow the change procedure in the role terms: material changes need notice and, where required, acceptance, and they apply only going forward.

13. Records

13.1 To the extent our systems record them, we keep records of Write Requests and of administrative actions on Accounts for security, billing, evidence and dispute resolution. Where we record IP addresses or user-agent strings for these purposes, we keep them as described in the Privacy Notice.