Legal

9 operations. Call each with POST https://app.chirply.io/api/v1/actions/<name> and a bearer token; the response is { "data": { "action", "summary", "result" } }. A read badge means the operation changes nothing; write requires the credential’s write scope.

Accept it

legal.accept_agency_dpawriteconfirmadmin only

Legally binds this account's company to the data processing agreement published by the agency that manages it. This is an electronic signature on a real contract between two businesses: it records the named person, their job title, the legal entity, the timestamp and the agreement version permanently, and the record cannot afterwards be edited or deleted. Only accept on behalf of someone with authority to bind that company. Fails if the managing agency has not published an agreement. Costs nothing. Accepting an agreement already accepted is harmless and changes nothing.

Marked confirm: this operation is irreversible, reaches real people, or spends money. Holding a credential is itself the confirmation for API and MCP callers — call it only when you mean it. The in-app assistant refuses to run it without a human approving first.

Also answers to sign our agency's DPA, accept the agency data processing agreement, agree to the client agreement.

Parameters

Field	Type	Required	Description
signer_name	string	required	Full name of the person accepting the agreement. This is recorded as the signature and must be a real person with authority to bind the legal entity — not an account name, a role, or an AI assistant.
legal_entity	string	required	Registered legal name of the company entering into the agreement. Often different from the account or trading name.
signer_title	string	optional	Job title of the person accepting, e.g. Director, Owner, Data Protection Officer. Optional, but it is what shows the signer had authority.

Example

curl -X POST https://app.chirply.io/api/v1/actions/legal.accept_agency_dpa \
  -H "Authorization: Bearer chp_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "signer_name": "Example",
    "legal_entity": "example"
  }'

Test with your API key

Over MCP the same operation is the tool legal_accept_agency_dpa at https://app.chirply.io/api/mcp, same bearer token, same input.

Accept the agreement

legal.accept_dpawriteconfirmadmin only

Legally binds this account's company to Chirply's Data Processing Agreement, including the Standard Contractual Clauses for transfers out of the EEA and UK. This is an electronic signature on a real contract: it records the named person, their job title, the legal entity, the timestamp and the agreement version permanently, and the record cannot afterwards be edited or deleted. Only accept on behalf of someone with authority to bind that company. Costs nothing. Accepting a version already accepted is harmless and changes nothing.

Also answers to sign the DPA, accept the data processing agreement, agree to the DPA.

Parameters

Field	Type	Required	Description
signer_name	string	required	Full name of the person accepting the agreement. This is recorded as the signature and must be a real person with authority to bind the legal entity — not an account name, a role, or an AI assistant.
legal_entity	string	required	Registered legal name of the company entering into the agreement. Often different from the account or trading name — for example 'Bright Ads Holdings Ltd' rather than 'Bright Ads'.
signer_title	string	optional	Job title of the person accepting, e.g. Director, Owner, Data Protection Officer. Optional, but it is what shows the signer had authority.

Example

curl -X POST https://app.chirply.io/api/v1/actions/legal.accept_dpa \
  -H "Authorization: Bearer chp_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "signer_name": "Example",
    "legal_entity": "example"
  }'

Test with your API key

Over MCP the same operation is the tool legal_accept_dpa at https://app.chirply.io/api/mcp, same bearer token, same input.

Client agreement

legal.agency_dparead

Reports the data processing agreement this agency publishes for its own client accounts to sign — the agency's registered legal entity, address and privacy contact, whether it is published or still a draft, how the underlying platform is described in the sub-processor annex, and which client accounts have signed it. Read-only; accepts nothing and changes nothing. Returns an unpublished draft for an agency that has not set one up.

Also answers to our client DPA, agency data processing agreement, which clients have signed, client agreement status.

Parameters

No parameters — POST an empty body.

Example

curl -X POST https://app.chirply.io/api/v1/actions/legal.agency_dpa \
  -H "Authorization: Bearer chp_live_…" \
  -H "Content-Type: application/json" \
  -d '{}'

Test with your API key

Over MCP the same operation is the tool legal_agency_dpa at https://app.chirply.io/api/mcp, same bearer token, same input.

Preview what your clients see

legal.agency_dpa_documentread

Returns the complete data processing agreement exactly as a client account reads and signs it — the parties, every numbered clause, and Annexes I to III — both as structured sections and as plain text. For an agency it renders the agency's last SAVED client agreement whether it is published or still a draft, so the text can be proof-read before 'legal.set_agency_dpa' publishes it; pass client_account_id to render one client account's own copy, with that account's name as Controller. An incomplete draft returns the particulars still missing instead of a document. For a client account it returns the agreement its agency has published, or nothing if none is. Read-only; publishes, signs and sends nothing.

Also answers to preview the client agreement, show the agreement our clients sign, read the client DPA before publishing, full text of the agency data processing agreement.

Parameters

Field	Type	Required	Description
client_account_id	string (uuid)	optional	Agencies only: the id of one of this agency's own client accounts, to render that account's copy with its name in the Controller row. Omit it to render the agency preview, whose Controller row reads 'Each client account, under its own name'. Refused for a client account, and for an id that is not a client account of this agency.

Example

curl -X POST https://app.chirply.io/api/v1/actions/legal.agency_dpa_document \
  -H "Authorization: Bearer chp_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "client_account_id": "2f6a1c1e-6c3b-4c62-9f6e-8a2d4b7c9e11"
  }'

Test with your API key

Over MCP the same operation is the tool legal_agency_dpa_document at https://app.chirply.io/api/mcp, same bearer token, same input.

Agreement with your agency

legal.agency_dpa_statusread

For a client account managed by an agency, reports whether this account has accepted the agency's data processing agreement, and returns the signature record — the version, the legal entity, who accepted it and when. Returns nothing in force for an account whose agency has not published one, in which case the platform's own agreement applies instead and 'legal.dpa_status' is the one to ask. Read-only.

Also answers to have we signed our agency's DPA, agreement with our agency, client DPA status.

Parameters

No parameters — POST an empty body.

Example

curl -X POST https://app.chirply.io/api/v1/actions/legal.agency_dpa_status \
  -H "Authorization: Bearer chp_live_…" \
  -H "Content-Type: application/json" \
  -d '{}'

Test with your API key

Over MCP the same operation is the tool legal_agency_dpa_status at https://app.chirply.io/api/mcp, same bearer token, same input.

Data Processing Agreement status

legal.dpa_statusread

Reports whether this account has accepted the current Data Processing Agreement, and returns the signature record — the version accepted, the legal entity, who accepted it, their job title, and when. Use it to answer 'do we have a DPA in place?' or to find accounts still on a superseded version. Read-only; accepts nothing and changes nothing.

Also answers to do we have a DPA, is the DPA signed, data processing agreement status, GDPR agreement status.

Parameters

No parameters — POST an empty body.

Example

curl -X POST https://app.chirply.io/api/v1/actions/legal.dpa_status \
  -H "Authorization: Bearer chp_live_…" \
  -H "Content-Type: application/json" \
  -d '{}'

Test with your API key

Over MCP the same operation is the tool legal_dpa_status at https://app.chirply.io/api/mcp, same bearer token, same input.

Sub-processors

legal.list_subprocessorsread

Lists every vendor Chirply may use to process personal data on a customer's behalf — what each one does, the categories of data it can see, where it processes, and the date it was added. This is Annex III of the Data Processing Agreement. Poll it and diff the result to detect a change before the notice period expires. Read-only.

Also answers to list sub-processors, who are your vendors, which third parties see our data, annex III.

Parameters

No parameters — POST an empty body.

Example

curl -X POST https://app.chirply.io/api/v1/actions/legal.list_subprocessors \
  -H "Authorization: Bearer chp_live_…" \
  -H "Content-Type: application/json" \
  -d '{}'

Test with your API key

Over MCP the same operation is the tool legal_list_subprocessors at https://app.chirply.io/api/mcp, same bearer token, same input.

Save agreement

legal.set_agency_dpawriteconfirmadmin only

Publishes, updates, or unpublishes the data processing agreement this agency's client accounts sign, with the agency as processor and each client as controller. Publishing makes a real contract available for other businesses to sign electronically; the signatures it collects are permanent records. Setting disclosure to 'generic' removes the platform provider's name from the sub-processor annex, which preserves white-label branding but weakens the client's Article 28(2) position — prefer 'named' unless the agency has decided otherwise. Costs nothing and sends nothing. Unpublishing does not revoke agreements already signed.

Also answers to publish our client DPA, set up the agency data processing agreement, update the client agreement.

Parameters

Field	Type	Required	Description
enabled	boolean	required	True publishes the agreement to every client account under this agency; false keeps it a private draft that no client can see or sign. Publishing requires the legal entity, address and privacy contact to be filled in.
legal_entity	string	optional	The agency's registered legal name — the party each client is contracting with. Often different from the trading name, e.g. 'Bright Ads Holdings Ltd' rather than 'Bright Ads'. Required before publishing.
registered_address	string	optional	The agency's registered address, as it should appear in the contract. Required before publishing.
privacy_contact	string	optional	Email address where the agency's clients send data protection questions and their own customers' subject requests. Appears in the agreement. Required before publishing.
disclosure	"named" \| "generic"	optional	How the underlying platform appears in the client's sub-processor annex. 'named' identifies the platform provider and is the Article 28(2)-compliant default. 'generic' describes it by function only, preserving white-label branding at the cost of a weaker disclosure position. Defaults to 'named'.
governing_law	string	optional	The jurisdiction whose law governs the agreement and whose courts hear a dispute about it, written as it should read in the contract, e.g. 'England and Wales', 'Scotland', or 'the State of Delaware'. Required before publishing.
retention_days	integer	optional	How many days after the end of the service the agency undertakes to delete or return a client's personal data. This is a binding commitment to every client that signs, not a platform setting — it appears in the duration and return clauses. Between 1 and 365; defaults to 30.
privacy_policy_url	string	optional	Optional https link to the agency's own privacy notice, linked from the duration clause. Must be a full web address; anything else is refused. Send an empty string to remove it.
additional_terms	string	optional	Optional clauses the agency adds in its own words, rendered verbatim as the final numbered section of the agreement its clients sign — liability caps, notice addresses, or an existing services agreement to incorporate. The platform-derived clauses above it cannot be edited, because they describe how the platform actually behaves. Send an empty string to remove them.

Example

curl -X POST https://app.chirply.io/api/v1/actions/legal.set_agency_dpa \
  -H "Authorization: Bearer chp_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true
  }'

Test with your API key

Over MCP the same operation is the tool legal_set_agency_dpa at https://app.chirply.io/api/mcp, same bearer token, same input.

Announced sub-processor changes

legal.subprocessor_changesread

Lists announced changes to the sub-processor list (Annex III of the Data Processing Agreement) — vendors being added, replaced or removed, what each does, which personal data it can access, where it processes, and the date the change takes effect — including those that took effect or were withdrawn in the last 90 days. Every change is announced at least 30 days before it takes effect, by email to every account that has accepted the DPA and to public subscribers. Poll it to detect a change inside the notice period. Platform admins may pass include_drafts to also see unannounced drafts with delivery counts. Read-only.

Also answers to upcoming sub-processor changes, new sub-processors, planned vendor changes, subprocessor change notice.

Parameters

Field	Type	Required	Description
include_drafts	boolean	optional	Platform admins only: also return drafts that have not been announced, and the delivery counts (sent, pending, failed, skipped) of every change. Refused for anyone else.

Example

curl -X POST https://app.chirply.io/api/v1/actions/legal.subprocessor_changes \
  -H "Authorization: Bearer chp_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "include_drafts": true
  }'

Test with your API key

Over MCP the same operation is the tool legal_subprocessor_changes at https://app.chirply.io/api/mcp, same bearer token, same input.