endpointr is a multi-tenant REST gateway. Each tool here mirrors one HTTP
endpoint under /v1/*. The tool name encodes the route shape:
endpointr_<group>_<resource>_<verb>
where verb is one of: list (GET collection), get (GET by id), query
(GET with query params), create (POST), update (PUT), delete (DELETE).

Tool arguments mirror the HTTP request body / path id / query string.
Most create/update tools accept an open body object — the schema lists
documented fields, but handlers commonly accept additional keys.

When the stored credential a call resolves carries an optional account_name
(e.g. distinguishing a "Conzent" Stripe account from a "Rexultz" one), the
response includes an _account object — {"name": …, "service": …} — naming
which account the call hit. Absent that field, no account_name was configured.

This connector is a TidyCal relay (https://tidycal.com/api) exposed through
endpointr — read AND write access to your TidyCal scheduling data (unlike
TidyCal's own read-only MCP). Each tool mirrors one TidyCal REST endpoint. Tool
names follow:
endpointr_tidycal_tidy_cal_<resource>_<verb>
where verb is one of: list (GET collection), query (GET with query params),
get (GET by id), create (POST/PATCH upstream), delete (DELETE).

Resources:
- me your account profile (list; GET /me).
- bookings query/get scheduled bookings; create books a slot on a
booking type (create REQUIRES booking_type_id in the
body, plus {name, email, timezone} and either starts_at
or a bookings[] array for packages).
- booking-cancel cancel a booking (create {booking_id, reason?}).
- booking-types query your booking types; create a new one
({title, description, duration_minutes, url_slug, …}).
- timeslots query bookable slots for a booking type — REQUIRES
booking_type_id, starts_at, ends_at (UTC).
- contacts query/create contacts.
- teams query/get teams you own or belong to.
- team-bookings query a team's bookings — REQUIRES team_id.
- team-users query/invite team members (create {team_id, email,
role_name?}); remove with a composite id teamId:teamUserId.
- team-booking-types query/create a team's booking types — REQUIRES team_id.
- accounts list the configured TidyCal account labels (see below).

MCP note: there is no query string over MCP, so resources that need a parent id
take it in the query arg (booking_type_id / team_id) for list verbs, in the
body for create, and as a composite parent:child id for get/delete.

Multiple TidyCal accounts. One login can hold several TidyCal accounts, each
stored under its own credential tidycal:<label> via
PUT /v1/credentials/tidycal:<label> {api_key:'…'} (e.g. tidycal:work). EVERY
tool (except accounts-list) accepts an optional top-level account argument
naming which account to target. When more than one account is configured,
account is REQUIRED — a call that omits it is rejected with the list of valid
labels. Call endpointr_tidycal_tidy_cal_accounts_list to see the labels. If only
a single unlabelled tidycal credential exists, account may be omitted.

Authentication. The connector OAuth establishes which endpointr customer you
are. The upstream TidyCal token (a personal access token; API access needs a
paid/Pro plan) is resolved per customer from the credential vault — store it
once via PUT /v1/credentials/tidycal {api_key:'…'}. Alternatively pass
api_key inline in any tool's body/query for per-request passthrough; it is
stripped before the request reaches TidyCal.

Tool arguments mirror the HTTP request body / path id / query string. Most
create tools accept an open body object — the schema lists documented fields,
but handlers forward additional keys to TidyCal verbatim.

This connector is a Missive relay. Each tool mirrors one Missive REST
endpoint (https://public.missiveapp.com/v1/) exposed through endpointr.
Tool names follow:
endpointr_mail_missive_<resource>_<verb>
where verb is one of: query (GET list with query params), get (GET by id),
create (POST), update (PUT/PATCH upstream), delete (DELETE).

Resources: conversations, messages, contacts, drafts, posts (internal
comments), tasks — plus the id-discovery lists: organizations, teams, users,
shared-labels, contact-books (each takes no parameters).

Where ids come from (chain these): conversation id ← conversations list (no
params; 25 most recent from the All mailbox) or query (mailbox filters);
message id ← messages query with conversation=<id>; contact_book ←
contact-books list; organization ← organizations list; team / user /
shared-label ids ← their lists. Draft and task ids come from their create
responses — Missive has no list endpoint for either (upstream limitation).

Authentication. The connector OAuth establishes which endpointr customer
you are. The upstream Missive API key (a missive_pat-… token) is resolved
per customer from the credential vault — store it once via
PUT /v1/credentials/missive {api_key:…}. Alternatively, pass api_key
inline in any tool's body/query for per-request passthrough; it is stripped
before the request reaches Missive.

Tool arguments mirror the HTTP request body / path id / query string. Most
create/update tools accept an open body object — the schema lists
documented fields, but handlers commonly accept additional keys.

This connector bundles Meta's (Facebook/Instagram) Graph APIs exposed through
endpointr: the Marketing API (ads) and the Conversations API (Messenger +
Instagram messaging). Each tool mirrors one REST endpoint. Tool names follow:
endpointr_marketing_<resource>_<verb> (Marketing API — /v1/marketing/*)
endpointr_messaging_<resource>_<verb> (Conversations API — /v1/messaging/*)
where verb is one of: list (GET collection), query (GET with query params),
get (GET by id), create (POST), update (PUT), delete (DELETE).

Marketing API (group marketing, vault slot meta-ads):
- ad-accounts the ad accounts the token can see (list/get). business_id
in the credential scopes discovery to one Business Manager.
- campaigns / ad-sets / ads the campaign hierarchy — full CRUD.
- creatives / ad-images / ad-videos creative assets (image/video upload;
ad-videos supports sync + async upload).
- audiences custom + lookalike audiences.
- pages Facebook Pages the token manages.
- pixels datasets + the Conversions API (server-side events).
- catalogs Commerce product catalogs.
- leads lead ads + lead forms.
- insights performance metrics (spend, impressions, actions, ROAS).
- auth Meta token introspection (debug-token, granted scopes) and
short-lived -> long-lived extension (create {action:'extend'}).
- webhook-subscriptions activate inbound meta-ads webhooks.

Conversations API (group messaging, vault slot meta-messaging):
- channels connected Pages / Instagram accounts (list/get). Listing
discovers each Page's access token and caches it.
- conversations list/read Messenger + Instagram threads (pass page_id,
platform=messenger|instagram).
- messages read messages (query by conversation_id) AND the Send
API (create): text, attachments, templates, quick
replies, plus sender actions (typing_on/typing_off/
mark_seen via {action,page_id,recipient_id}).
- profile look up a messaging user's public profile by PSID/IGSID
(pass page_id).
- messenger-profile persistent menu, ice breakers, greeting, get-started
button per Page (query/create/delete).
- webhook-subs activate inbound meta-messaging webhooks per Page
(subscribed_apps).
- token introspect / extend the stored messaging Meta token.

Authentication. The connector OAuth establishes which endpointr customer you
are. The two surfaces use SEPARATE vault slots (a login can wire either or
both), each resolved per customer from the credential vault:
- Marketing: PUT /v1/credentials/meta-ads {access_token, app_id, app_secret,
business_id?, api_version?}. Prefer a long-lived System User token (or
extend a short-lived user token via marketing/auth {action:'extend'}).
- Messaging: PUT /v1/credentials/meta-messaging {access_token, app_id,
app_secret}. The token needs messaging scopes (pages_messaging,
pages_show_list, pages_manage_metadata, pages_read_engagement, and for
Instagram instagram_basic + instagram_manage_messages, plus
business_management). Per-Page access tokens are auto-discovered from
/me/accounts and cached encrypted — pass page_id on
conversation/message/profile calls so the right Page token is used.
app_secret backs HMAC verification of inbound webhook deliveries and token
extension. api_version pins the Graph version (default v24.0) per customer.

Tool arguments mirror the HTTP request body / path id / query string. Most
create/update tools accept an open body object — the schema lists documented
fields, but handlers forward additional keys to Meta verbatim.

This connector is a Cloudflare API relay (https://api.cloudflare.com/client/v4)
exposed through endpointr, scoped to managing zones (domains), DNS, Workers,
and Pages. Each tool mirrors one REST endpoint under /v1/cloudflare/*. Tool
names follow:
endpointr_cloudflare_<resource>_<verb>
where verb is one of: list (GET collection), query (GET with query params),
get (GET by id), create (POST), update (PUT/PATCH), delete (DELETE).

Resources:
- zones list/get/create/update/delete zones. Creating a zone is
how you ADD A NEW DOMAIN ({name, account_id?}). query
filters by name/status/account_id.
- dns-records DNS records, scoped to a zone. query lists them and
REQUIRES zone_id. create/update carry zone_id in the
body. get/delete take a composite id zoneId:recordId.
- workers Worker scripts (account-scoped). list/get/delete by
script name; create uploads an ES-module worker
({name, script, compatibility_date?, bindings?}).
- worker-routes route patterns that run a Worker, scoped to a zone.
query REQUIRES zone_id; delete takes zoneId:routeId.
- pages-projects Cloudflare Pages projects (account-scoped). list/get/
create/delete by project name.
- pages-deployments deployments per project. query REQUIRES project_name;
create triggers a deploy ({project_name, branch?});
get/delete take a composite id projectName:deploymentId.
- cf-accounts list/get the accounts the token can access — use this to
discover the account_id Workers/Pages need.
- token-verify verify the stored API token is active.
- cf-account-labels list the credential LABELS configured for this customer
(one per company) — the values the account selector
takes. Takes no selector itself.
- cache-purge clear a zone's cache. create REQUIRES zone_id in the
body plus one mode: purge_everything:true, or a
files / tags / hosts / prefixes array (the last
three are Enterprise-only).
- cache-settings read/update a zone's cache config. query REQUIRES
zone_id and returns cache_level / browser_cache_ttl /
development_mode / always_online / sort_query_string_for_cache.
update takes the setting name as the id and
{zone_id, value} in the body (development_mode on/off,
cache_level aggressive/basic/simplified, browser_cache_ttl
in seconds).

MCP note: there is no query string over MCP, so resources that need a parent id
take it in the query arg (zone_id / project_name) for list verbs, in the
body for create/update, and as a composite parent:child id for get/delete.

Multiple Cloudflare accounts. One login can hold several Cloudflare logins
(one per company, e.g. SitePoint Systems and Conzent), each stored under its
own credential cloudflare:<label> via PUT /v1/credentials/cloudflare:<label>
{api_token, account_id} (e.g. cloudflare:conzent). EVERY tool (except
cf-account-labels) accepts an optional top-level account argument naming
which login to use. When more than one label is configured, account is
REQUIRED — a call that omits it is rejected with the list of valid labels. Call
endpointr_cloudflare_cf_account_labels_list to see the labels. If only a single
unlabelled cloudflare credential exists, account may be omitted. Do not
confuse the two "accounts": account (the selector) picks the stored token;
account_id is Cloudflare's own account inside that login (see cf-accounts).
When the stored credential carries account_name, responses include
_account naming which login the call hit.

Authentication. The connector OAuth establishes which endpointr customer you
are. The upstream Cloudflare token is resolved per customer from the credential
vault — store it once via PUT /v1/credentials/cloudflare
{api_token, account_id}, or per company as cloudflare:<label> (see above).
Only API Token (Bearer) auth is supported; the token needs the relevant Zone /
Workers / Pages permissions. account_id is the default account for
account-scoped resources (Workers, Pages, accounts) and may be overridden
per-request via account_id.

Tool arguments mirror the HTTP request body / path id / query string. Most
create/update tools accept an open body object — the schema lists documented
fields, but handlers forward additional keys to Cloudflare verbatim.

This connector is an OpenProvider relay (https://api.openprovider.eu/v1beta)
exposed through endpointr, scoped to domain registration and DNS. Served at
openprovider.mcp.endpointr.com. Each tool mirrors one OpenProvider REST endpoint
under /v1/openprovider/*. Tool names follow:
endpointr_openprovider_op_<resource>_<verb>
where verb is one of: query (GET with query params), get (GET by id),
create (POST), update (PUT), delete (DELETE).

Typical flow: op-customers create (get an owner handle) -> op-domain-check
(is the name free?) -> op-domains create (register) -> op-zones / op-dns-records
(set up DNS).

Resources:
- op-customers The reusable contact HANDLE (e.g. XX123456-XX) a domain
references as owner/admin/tech. Full CRUD; the id is the
handle string. create returns data.handle. You need at
least one before registering a domain. Required to create:
name, address, phone, email (see the tool's minimal body).
- op-domain-check create = check availability (+ price with with_price).
Body {domains:[{name,extension}], with_price?}. status
free = available, active = taken.
- op-domains query/get/create/update/delete domains. create with no
action REGISTERS ({domain:{name,extension}, owner_handle,
period, name_servers|ns_group}); create with action:'renew'
+ id + period renews. get/update/delete take the NUMERIC
domain id.
- op-zones DNS zones CRUD. id = the zone NAME (full domain, e.g.
example.com). get returns records inline. update is how you
EDIT/REMOVE records — send them grouped under
records:{add,remove,replace,update} (records have no id;
matched by their {type,name,value} tuple).
- op-dns-records query = list a zone's records (name required = the domain).
create = APPEND records to a zone
({domain, records:[{type,name,value,ttl}]}). For edit/remove
use op-zones update.

MCP note: there is no query string over MCP, so list filters go in the query
arg; the path id goes in the id arg — a NUMERIC domain id (op-domains), a
customer HANDLE (op-customers), or a zone NAME/full domain (op-zones). op-dns-records
takes the zone in the body/query, not as a path id.

Every response is the OpenProvider envelope {code, data, desc, warnings} —
code:0 is success and the useful payload is under data.

Authentication. The connector OAuth establishes which endpointr customer you
are. OpenProvider issues a short-lived Bearer token from username/password; the
relay logs in, caches the token, and re-logs-in on expiry, so you never handle
tokens. Store the login once via PUT /v1/credentials/openprovider
{username, password} (optional ip, default 0.0.0.0 = any IP — set it if the
account restricts API access by IP). Vault-only: credentials are never accepted
per-request.

Tool arguments mirror the HTTP request body / path id / query string. Most
create/update tools accept an open body object — the schema lists documented
fields, but handlers forward additional keys to OpenProvider verbatim (so the
full CreateDomain / CreateCustomer / UpdateZone request shapes are supported).

This connector is a Cal.com API v2 relay (https://api.cal.com/v2) exposed
through endpointr, scoped to scheduling: event types, availability slots,
bookings, and availability schedules. Served at
calcom.calendars.mcp.endpointr.com. Each tool mirrors one REST endpoint under
/v1/calcom/*. Tool names follow:
endpointr_calcom_cal_com_<resource>_<verb>
where verb is one of: query (GET with query params), get (GET by id),
list (GET collection), create (POST), update (PUT/PATCH), delete (DELETE).

Typical flow: event-types (find an eventTypeId) -> slots (find an open time)
-> bookings create -> bookings query/get and cancel/reschedule.

Resources:
- event-types query = list bookable meeting types (filters: username,
eventSlug, orgSlug, ...). Each event type's numeric id is the
eventTypeId slots + bookings need. get = one by id.
- slots query = available times for an event type over a date range.
REQUIRES start + end (UTC, ISO 8601 / YYYY-MM-DD) AND an
event identifier (eventTypeId, or eventTypeSlug + username).
Optional timeZone, duration. Response data is grouped by
date.
- bookings query = list bookings (filters: status, attendeeEmail,
eventTypeId, limit, cursor, ...). get = one by its uid. create
= book a meeting ({start, eventTypeId, attendee:{name, email,
timeZone}}) OR act on an existing booking via an action field
+ bookingUid: action ∈ cancel | reschedule (needs new start)
| confirm | decline. Cal.com has no PUT/DELETE for bookings —
use create+action.
- schedules list/get/create/update/delete availability schedules (working
hours). create REQUIRES name + timeZone; isDefault
defaults false; availability defaults Mon-Fri 09:00-17:00.
- accounts list the configured Cal.com account labels (see below).

MCP note: there is no query string over MCP, so list filters go in the query
arg, the booking uid / schedule id / event type id go in the id arg (or, for
booking cancel/reschedule/confirm/decline, as bookingUid inside the create
body alongside action). The correct dated cal-api-version header is set by
the gateway per endpoint — you never send it.

Multiple Cal.com accounts. One login can hold several Cal.com accounts, each
stored under its own credential calcom:<label> via
PUT /v1/credentials/calcom:<label> {api_key:"cal_live_…"} (e.g. calcom:work).
EVERY tool (except accounts-list) accepts an optional top-level account
argument naming which account to target. When more than one account is
configured, account is REQUIRED — a call that omits it is rejected with the
list of valid labels. Call endpointr_calcom_cal_com_accounts_list to see the
labels. If only a single unlabelled calcom credential exists, account may be
omitted.

Authentication. The connector OAuth establishes which endpointr customer you
are. The upstream Cal.com API key is resolved per customer from the credential
vault — store it once via PUT /v1/credentials/calcom {api_key:"cal_live_…"}
(test keys start cal_…), or per account as calcom:<label> (see above).
Alternatively pass api_key inline in any tool's body/query for per-request
passthrough; it is stripped before the request reaches Cal.com.

Tool arguments mirror the HTTP request body / path id / query string. Most
create/update tools accept an open body object — the schema lists documented
fields, but handlers forward additional keys to Cal.com verbatim.

This connector is a Dinero accounting relay (api.dinero.dk) exposed through
endpointr. Each tool mirrors one Dinero REST endpoint. Tool names follow:
endpointr_accounting_dinero_<resource>_<verb>
where verb is one of: query (GET list / read sub-operation), get (GET by id),
list (GET collection), create (POST), update (PUT), delete (DELETE).

Resources: invoices (+ reminders), contacts (+ notes), products, accounts,
accounting-years, ledger-items, entries, vouchers (manual / purchase /
purchase credit notes), purchase-vouchers (payments), sales-credit-notes,
trade-offers, voucher-templates, reports, webhooks, integrations,
organizations (+ verification), state-of-account, business-goals, files,
attachments, sms, electronic-invoice, settings, countries, vat-types,
unified-vouchers.

Sub-operations and nested resources are folded onto an action field (and a
type field for the vouchers family) because the gateway publishes flat REST
routes only — e.g. book an invoice with create {action:'book', id:'…'}, read
a PDF with query {action:'pdf', id:'…'}. Each tool's description lists its
available actions and the ids they require. Reads and deletes of nested
resources (notes, reminders, payments, attachment files) are reached through
query/create with the relevant action, not the bare get/delete tool
(which only carries a single path id).

Authentication. The connector OAuth establishes which endpointr customer you
are. The upstream Dinero token uses Visma Connect OAuth2 (scopes
dineropublicapi:read dineropublicapi:write offline_access), minted by the
admin "Connect Dinero" flow and auto-refreshed by the relay against
connect.visma.com when it expires. Alternatively pass access_token +
organization_id inline on any call (per-request passthrough; both are
stripped before the request reaches Dinero).

Companies. One Visma login reaches several Dinero organisations, and each
one the admin exposed is a labelled company (e.g. sitepoint, conzent).
Every tool takes an optional top-level account argument naming the company
label. With exactly one company configured it may be omitted; with several
it is REQUIRED — the relay refuses to guess which company a call (and a
posting) lands in and lists the valid labels instead. Discover them with
endpointr_accounting_dinero_companies_list ({companies:[{label, name,
organization_id}], account_required}). Responses carry _account naming the
company that was hit. Passing organization_id inline bypasses the label.

Spend reports. endpointr_accounting_dinero_custom_reports_query aggregates a
company's ledger server-side for a period: totals with and without salary, by
type, by category, by account, by month, and (detail=detailed) the underlying
lines — so "what did we actually spend in August" is one call, not a pile of
raw entries. Every account in a report carries an ENGLISH type (income,
cost_of_goods, expense, salary, depreciation, financial_cost, tax, vat, bank,
receivable, payable, asset, liability, equity, other) with side (result |
balance) and type_source. The type comes from Dinero's own account
category (Salary, Administration Expenses, Vat Due, …, the same
grouping Dinero's result report uses), falling back to the standard chart by
account number; read the type, never guess from the account name, which
carries VAT-status suffixes like "med moms" that say nothing about the
account. action=chart returns the whole chart of
accounts classified the same way — read it once per company before trusting
numbers. Every report lists the accounts it EXCLUDED (with a reason) and the
ones it could not type (unmapped), so the definition can be tuned: save a
per-company definition with the ..._custom_reports_create tool
(account_types / category_types to fix a type, include_types to decide what
counts as spend, include/exclude ranges) and it applies to every later run for
that company. Use the raw entries and reports tools when you need Dinero's
own figures instead of the aggregation.

Tool arguments mirror the HTTP request body / path id / query string. Most
create/update tools accept an open body object — the schema lists documented
fields, but handlers forward additional keys to Dinero verbatim.

This connector is a Billy accounting relay (api.billysbilling.com/v2 — Billy
by Shine, mit.billy.dk) exposed through endpointr. Each tool mirrors one Billy
REST resource. Tool names follow:
endpointr_accounting_billy_<resource>_<verb>
where verb is one of: query (GET list / read sub-operation), get (GET by id),
list (GET collection), create (POST), update (PUT, partial), delete (DELETE).

Resources: invoices (+ invoice lines, late fees, reminders, reminder
associations), bills (+ bill lines), contacts (+ contact persons), products
(+ product prices), accounts (+ account groups, account natures), postings
and transactions (the ledger), daybooks and daybook transactions (+ lines:
manual journal entries), bank lines (+ matches, subject associations), bank
payments, attachments and files, balance modifiers, contact balance payments
and postings, tax rates (+ deduction components), sales tax accounts / meta
fields / payments / returns / rules / rulesets, organizations, users, and the
reference data (countries, country groups, currencies, cities, zipcodes,
states, locales).

Envelope. Billy answers with the record under a root key — a single record as
{"invoice": {...}}, a list as {"invoices": [...], "meta": {"paging": {...}}} —
and the relay returns that verbatim. A write returns EVERY record it changed
(creating an invoice line returns the recalculated invoice too). On create and
update send the record's fields directly; the relay wraps them in Billy's
singular root key and adds organizationId.

Lists page with page and pageSize (default and max 1000), sort with
sortProperty + sortDirection, sideload with include
(e.g. invoice.lines:embed,invoice.contact:sideload), search with q.
Filters are named query params; date periods take year:2026,
month:2026-09, quarter:2026-3, dates:2026-01-01...2026-03-31,
from:/through:. Billy IGNORES unknown filter names silently, so on
invoices, bills, postings, bank lines, attachments and daybook transactions
the relay rejects unknown filters with the allowed list.

Operations Billy models as state changes or sub-endpoints are folded onto an
action field:
- invoices create: approve (id) books a draft — the only state change
Billy allows; email (id + contactPersonId, emailSubject, emailBody);
credit_note (id of the invoice to credit); deliver (id) sends an
e-invoice via NemHandel/Peppol. invoices query: pdf (id) returns the
PDF as base64; logs (id) the e-invoice delivery log.
- bills create: approve (id), credit_note (id).
- daybook transactions create: approve (id) books a manual entry.
- files create uploads a file from content_base64; files query
download (id) returns the bytes.
- users query: me = the user behind the token.
Payments: register a payment on invoices or bills with bank-payments create
(cashSide debit = money in, credit = money out; associations name
invoice:<id> / bill:<id>).

Authentication. The connector OAuth establishes which endpointr customer you
are. Upstream, a Billy access token is permanent and tied to ONE
organisation, so each company is a credential row billy:<label> holding
{access_token, organization_id, account_name}. Alternatively pass
access_token (+ organization_id) inline on any call (passthrough; both
are stripped before the request reaches Billy).

Companies. Every tool (except the companies list) takes an optional
top-level account argument naming which company to target, by label. When
more than one company is configured, account is REQUIRED — a call that
omits it is rejected with the list of valid labels; the relay never guesses
which company's books a write lands in. Call
endpointr_accounting_billy_companies_list to see the labels (it also confirms
each token against Billy). If only one company is configured, account may
be omitted. Responses carry _account naming the company the call hit.

Tool arguments mirror the HTTP request body / path id / query string. Most
create/update tools accept an open body object — the schema lists documented
fields, but handlers forward additional keys to Billy verbatim.

This connector is an e-conomic (Visma e-conomic) accounting relay exposed
through endpointr. Each tool mirrors one e-conomic resource. Tool names
follow:
endpointr_accounting_economic_<resource>_<verb>
where verb is one of: query (GET list / read sub-operation), get (GET by id),
list (GET collection), create (POST), update (PUT), delete (DELETE).

Two upstream APIs behind one relay. The classic REST API
(restapi.e-conomic.com) carries the bulk: agreements/self, accounting years,
accounts, app roles, currencies, customer groups, customers, departmental
distributions, departments, employees, invoices (drafts → booked → sent /
paid / unpaid / overdue), orders, quotes, journals, layouts, payment terms,
payment types, product groups, products, supplier groups, suppliers, units,
VAT accounts, VAT zones. The per-domain APIs (apis.e-conomic.com) carry what
the classic API lacks: draft entries and BOOKING, booked entries (the
ledger), dimensions, documents (voucher attachments), webhooks, projects
(time, mileage), subscriptions, budgets, and the write side of accounts,
products, journals and suppliers' contacts.

Conventions. Classic lists answer {collection, pagination} and take
skippages + pagesize (max 1000), filter (prop$eq:value, chained with
$and:/$or:, operators $ne $gt $gte $lt $lte $like $in $nin, string values
escaped: $ ( ) * , [ ] as $$ $( $) $* $, $[ $]) and sort (-prop
descending). Domain lists are cursor-based ({cursor, items}, 1000 per page)
or paged (paged=true, pageSize ≤ 100, skipPages, sort) with count=true.
Domain writes: POST creates; PUT carries the record's id in the BODY and a
mandatory objectVersion (409 = stale, re-read and retry). Sub-resources
and lifecycle steps are folded onto action and kind (see each tool).

Booking. A draft invoice becomes booked with invoices create
{action:"book", id: <draft number>}. Manual entries are draft entries
(draft-entries create) booked with {action:"book"} (whole journal),
{action:"book_entries", entry_numbers:[…]} or {action:"book_interval",
from, to}. The ledger is booked-entries query (filter on date/account).

Authentication. The connector OAuth establishes which endpointr customer you
are. Upstream, every call carries our developer app's X-AppSecretToken
(stored once on the economic credential) and the company's
X-AgreementGrantToken (economic:<label>, one per agreement, minted by
"Connect e-conomic" in the admin). Alternatively pass app_secret_token +
agreement_grant_token inline on any call (passthrough; both are stripped
before the request). idempotency_key on a create/update is forwarded as
Idempotency-Key.

Agreements (companies). Every tool (except the agreements list) takes an
optional top-level account argument naming which company to target, by
label. When more than one agreement is configured, account is REQUIRED —
a call that omits it is rejected with the valid labels; the relay never
guesses whose books a write lands in. Call
endpointr_accounting_economic_agreements_list to see them (it also confirms
each grant against /self). Responses carry _account naming the company.

Tool arguments mirror the HTTP request body / path id / query string. Most
create/update tools accept an open body object — the schema lists documented
fields, but handlers forward additional keys to e-conomic verbatim.

This connector is a Uniconta accounting relay (api.uniconta.com — the
Uniconta Web API) exposed through endpointr. Tool names follow:
endpointr_accounting_uniconta_<resource>_<verb>
where verb is one of: query (list / read sub-operation), get (by key),
list (no params), create (POST), update (PUT), delete (DELETE).

THE MODEL. Uniconta is a table store with posting APIs on top. Every table
(255 of them) is reachable through the entities tool — query with filters,
insert, update, delete — and the family tools (debtors, creditors, items,
accounts, transactions, vat, finance-years, payment-terms, employees,
projects, subscriptions, bank-statements, budgets, exchange-rates,
warehouses, contacts) are the same calls fixed to one table with its key
property. Keys are Uniconta's own: a debtor/creditor/GL account by
Account, an item by Item, an order by OrderNumber, an invoice by
InvoiceNumber, a journal by Journal; the entities tool addresses any
row as Entity:RowId.

Posting is separate from tables: journals (GLJournal: draft lines in a
daily journal, check, post, post_daily, settle_bank), orders
(action=generate_invoice BOOKS the invoice from a sales order and returns
its PDF; kind=creditor for purchases), invoices (posted invoices + PDFs),
settlements (open items; settle / reopen), project-journals,
inventory-journals, production, documents (attachments + the voucher inbox).

Filter grammar (the filters array of {property, value}): equality by
default; ranges 01-01-2025..31-05-2025 (dates are dd-MM-yyyy); lists
100;110;129; wildcards *abc*; order_by + descending; skip + take
page. Any other key on a query is an equality filter on that property.
Field names and types for any table: entities query with action=fields.

Authentication. The connector OAuth establishes which endpointr customer
you are. Upstream, the relay logs in with the customer's Uniconta
Server-Login user (credential uniconta {username, password}) and binds the
session to the selected company; the token is cached per company. Or pass
access_token (+ company_id) inline on any call (per-request
passthrough; both are stripped before the request reaches Uniconta).

Companies. A company is a labelled credential row uniconta:<label>
{company_id, account_name}. Every tool takes an optional top-level account
argument naming the label; required when more than one company is
configured. endpointr_accounting_uniconta_companies_list lists them (and
the companies the login can reach) and takes no selector.

Uniconta answers errors as HTTP 200 text; the relay turns them into
errors with a status (401 re-logs in once, 404, 409, else 422) and the
text. Nothing in this connector has run against a live Uniconta yet — the
first session pins the response shapes.

This connector is endpointr's UNIFIED accounting API: one canonical surface
over every accounting system endpointr relays (Dinero, Billy, e-conomic,
Uniconta). Software binds a company to a provider once and then calls the
same tools whatever system is behind it. Tool names follow:
endpointr_unified_accounting_<resource>_<verb>
where verb is one of: query (GET list / read sub-operation), get (GET by id),
list (GET collection), create (POST), update (PUT, partial).

Resources: companies (the bindings — start here), capabilities (what each
provider supports), readiness (whether a company's books have what issuing
an invoice needs — ask it when a company is connected), accounts (the chart, every account with an English type),
accounting-years, customers and suppliers (email, phone and vat_number
are exact lookups — find a contact before creating it), products, quotes
(offers; an update replaces the whole quote and may return a new id), invoices (list/get/create
draft, then action: book, send, credit_note, register_payment; query
action=pdf), journal-entries (create draft, action: book, simulate),
entries (the ledger, debit-positive), vat-types, attachments, reports (the
spend report engine on any company).

Bindings. A binding is a credential row unified-accounting:<label>
{provider, account, account_name} pointing at that provider's own company
row (e.g. provider dinero, account conzent → dinero:conzent). It holds no
secret. EVERY tool (except companies) takes an optional top-level account
argument naming the binding; when more than one binding is configured it is
REQUIRED — a call that omits it is rejected with the valid labels. Call
endpointr_unified_accounting_companies_list to see them. Responses carry
_account (the binding) and _provider {provider, account, label} naming
which system answered.

Lowest common denominator, honestly. Every canonical record carries id (the
vendor id), provider and raw (the untouched vendor record) so nothing is
lost. What a provider cannot serve fails with error UNIFIED_UNSUPPORTED and
vendor_tool, the vendor connector's own tool that does it natively — call
that on the vendor connector for the edge case. Call
endpointr_unified_accounting_capabilities_query first when planning a
workflow: supported, partial (read the note), unsupported (use
vendor_tool), pending (the adapter is not built yet).

Account types. Accounts carry an English type — income, financial_income,
cost_of_goods, expense, salary, depreciation, financial_cost, tax, vat, bank,
receivable, payable, asset, liability, equity, other — from the shared
classification engine (definition overrides → the vendor's own category →
the standard Danish chart by number where the vendor uses it → the name).
Read type, never guess from a Danish account name. Ledger amounts are
DEBIT-POSITIVE on every provider: expenses positive, revenue negative.

Authentication. The connector OAuth establishes which endpointr customer you
are. The upstream credentials stay on each provider's own credential rows;
the unified layer never holds a token.

Tool arguments mirror the HTTP request body / path id / query string.

This connector bundles Google's measurement APIs — Search Console (read-only)
and Google Analytics 4 (Data reads + Admin reads AND writes) — exposed through
endpointr. Each tool mirrors one Google REST endpoint. Tool names follow:
endpointr_searchconsole_<resource>_<verb> (Search Console)
endpointr_analytics_data_ga4_<resource>_<verb> (GA4 Data API)
endpointr_analytics_admin_ga4_<resource>_<verb> (GA4 Admin API)
where verb is one of: list (GET collection), query (GET with query params),
get (GET by id), create (POST), update (PATCH), delete (DELETE).

Google Tag Manager is a SEPARATE connector (endpointr-tagmanager) — container,
tag, trigger and publish work lives there, not here.

Search Console (https://www.googleapis.com/webmasters/v3):
- sites list verified sites (list); get one by ?siteUrl=.
- search-analytics create = run a Search Analytics query (clicks,
impressions, CTR, position) for a property. Requires
siteUrl + startDate + endDate; dimensions optional.
- sitemaps query = list a property's sitemaps (requires siteUrl;
add feedpath for a single sitemap).
- url-inspection create = inspect one URL's index status on a property
(requires inspectionUrl + siteUrl).

GA4 Data API (https://analyticsdata.googleapis.com/v1beta):
- ga4-reports create = runReport (metrics × dimensions over dateRanges).
- ga4-realtime create = runRealtimeReport (last 30 minutes).
- ga4-metadata query = discover the dimensions/metrics a property exposes.
All require property (accepts properties/123456 or a bare 123456).

GA4 Admin API (https://analyticsadmin.googleapis.com/v1beta) — discovery AND
configuration. This is the half that SETS TRACKING UP on an account that
already exists:

- ga4-account-summaries list = every account + property in one call. Start
here; you need no ids to make this call.
- ga4-accounts list = accounts the user can access. An account CANNOT be
created through any Google API (a human must accept the
Terms of Service), so this list is the ceiling —
everything below hangs off one of these.
- ga4-properties query (requires ?account=) / get / create / update /
delete. create needs {account, displayName, timeZone};
set currencyCode too — GA4 defaults to USD and past data
is not restated. delete is a 63-day soft delete.
- ga4-data-streams query (requires ?property=) / get / create / update /
delete. Creating a WEB_DATA_STREAM is what MINTS THE
MEASUREMENT ID (webStreamData.measurementId, G-XXXXXXXXXX)
— the value a Google tag or a GTM googtag tag needs.
- ga4-key-events the GA4 UI's "conversions". query/get/create/update/
delete; create = {property, eventName, countingMethod}.
The event need not have fired yet.
- ga4-custom-dimensions / ga4-custom-metrics register event parameters so
they are queryable. A parameter with no custom dimension
is collected and then INVISIBLE — the step most tracking
setups miss. Archive (not delete) via
create {action:'archive', id}.
- ga4-google-ads-links query/create/update/delete. create = {property,
customerId} where customerId is the 10-digit GOOGLE ADS
id. This is what lets key events import as Ads
conversions.
- ga4-data-retention per-property singleton, addressed by the PROPERTY
id. New properties default to TWO_MONTHS; FOURTEEN_MONTHS
is almost always what you want, and it is not
retroactive.
- ga4-enhanced-measurement a WEB stream's automatic events (scrolls,
outbound clicks, site search, video, downloads, form
interactions). get/update by propertyId:streamId.
v1alpha — no v1beta equivalent exists.
- ga4-measurement-protocol-secrets list/get/create/delete per data stream
(needs BOTH property and stream). The secret + measurement
ID are the credentials for SERVER-SIDE events.

THE ID MODEL for the Admin tools: collection verbs (query/create) take the
parent as property (accepting properties/123456 or a bare 123456) — plus
stream one level down for measurement-protocol secrets. get/update/delete take
the target as id, either the full resource name Google returns in name
(properties/123/keyEvents/456) or the MCP-friendly colon composite of the same
ids in order (123:456).

UPDATES ARE PATCHES. Google rejects a patch that does not name the fields it
changes, so send only the fields you are changing and the relay derives
updateMask from your body's top-level keys. Pass update_mask explicitly to
override — required when targeting a nested leaf, e.g.
{update_mask:'webStreamData.defaultUri', webStreamData:{defaultUri:'https://…'}}.

A NEW SITE, END TO END: ga4-accounts (pick the account) -> ga4-properties create
-> ga4-data-streams create (copy the measurement ID out of the response) ->
ga4-data-retention update -> ga4-key-events create (one per conversion) ->
ga4-custom-dimensions create (one per parameter your tags will send) ->
ga4-google-ads-links create. Then install the measurement ID on the site —
that part lives in the tagmanager connector, or in your own deploy.

Authentication. The connector OAuth establishes which endpointr customer you
are. The upstream Google token is resolved per customer from the credential
vault — store a refresh-triplet once via PUT /v1/credentials/google
{client_id, client_secret, refresh_token} and endpointr mints short-lived
access_tokens on every call. Alternatively pass oauth_token (a fresh
access_token) or the refresh-triplet inline on any call (per-request
passthrough; the credential fields are stripped before the request reaches
Google). The refresh_token must be minted with the scopes you need:
- https://www.googleapis.com/auth/webmasters.readonly (Search Console)
- https://www.googleapis.com/auth/analytics.readonly (Analytics Data+Admin reads)
- https://www.googleapis.com/auth/analytics.edit (GA4 Admin WRITES)

WRITING to the GA4 Admin API needs analytics.edit. Both Google connect flows
now request it: the shared google slot ("Connect with Google") and the
dedicated google-analytics slot ("Connect Google Analytics"), which exists for
customers who want GA4 write consent kept off the slot Tasks and Search Console
share. Every GA4 tool resolves its token as: credentials in the request bag ->
the google-analytics slot when the customer has one -> the google slot.

Widening the scope list grants nothing retroactively: a refresh_token minted
before analytics.edit was requested still carries only its original scopes, so a
write on such a grant comes back as Google's own 403 PERMISSION_DENIED until the
customer re-runs Connect once. Reads are unaffected either way.
When a token is minted from the vault, the new access_token is surfaced in the
response as refreshed_access_token so clients can cache it (~1h TTL).

Tool arguments mirror the HTTP request body / path id / query string. Most
create/update tools accept an open body object — the schema lists documented
fields, but handlers forward additional keys to Google verbatim (so the full
runReport / searchAnalytics request shapes are supported).

This connector is a Google Ads API (v25, REST) relay exposed through
endpointr: FULL account management — reads via GAQL, writes via each
resource's :mutate endpoint (one operation per call), plus the special
service methods (conversion uploads, keyword planning, recommendations,
account creation, Customer Match, experiments). Each tool mirrors one
REST endpoint under /v1/googleads/*. Tool names follow:
endpointr_googleads_<resource>_<verb>
where verb is one of: list (GET collection), query (GET with query
params), create (POST), update (PUT), delete (DELETE).

Typical flow: accessible-customers list (discover which Ads accounts you
can reach) -> any resource's query tool (canned GAQL id-discovery; every
row's resourceName is the id its update/delete take) -> create/update/
delete. reports create runs raw GAQL for anything the canned lists don't
cover.

THE ID MODEL (read this first): update/delete tools take the target as
id, in any of three forms — the full resource name exactly as query
tools return it (customers/<cid>/<resource>/<rid>), the composite
<customer_id>:<resource_id> (the MCP-friendly form; put the account's 10
digits before the colon), or a bare id when customer_id rides in the
update body. Google's own composite resource ids keep their ~ (an ad is
<adGroupId>~<adId>; an asset link <assetId>~<fieldType>).

Resources, grouped:
- Discovery & reporting: accessible-customers (list = every account the
OAuth grant reaches directly; empty usually means MCC-only access —
set login_customer_id to the manager and query customer_client via
reports), reports (create = raw GAQL SELECT, REQUIRES customer_id +
query; pageSize/pageToken page up to 10,000 rows).
- Campaign structure: campaign-budgets, ad-campaigns, ad-groups,
ad-group-ads, keywords (ad-group criteria of type KEYWORD).
- Targeting & bidding: campaign-criteria (geo/language/schedule/device/
negatives), ad-group-criteria (all criterion types),
customer-negative-criteria, shared-sets + shared-criteria +
campaign-shared-sets (negative keyword lists), labels +
campaign/ad-group/ad-group-ad-labels, bidding-strategies (portfolio),
campaign-bid-modifiers, ad-group-bid-modifiers.
- Assets: assets (permanent — NO delete; detach links instead),
asset-sets + asset-set-assets + campaign/ad-group-asset-sets, and the
link tables customer-assets / campaign-assets / ad-group-assets.
- Performance Max: asset-groups, asset-group-assets,
asset-group-listing-group-filters, asset-group-signals.
- Conversions & goals: conversion-actions, conversion-uploads (create
only; action = click|call|adjustments; Google requires
partialFailure:true), conversion-value-rules + -rule-sets,
conversion-custom-variables, custom-conversion-goals,
customer-conversion-goals + campaign-conversion-goals,
conversion-goal-campaign-configs, goals + campaign-goal-configs
(v25 unified goals).
- Audiences: user-lists, offline-user-data-jobs (Customer Match:
create job -> action add_operations -> action run -> poll query),
ad-audiences (the audience resource), custom-audiences,
remarketing-actions.
- Planning: keyword-planning (create only; action = ideas|
historical_metrics|forecast_metrics), geo-targets (query the
constants table; create = suggest by location name, no customer_id),
recommendations (query + create with REQUIRED action apply|dismiss|
generate — apply changes live spend).
- Account ops: customers (query own row; create = NEW client account
under an MCC; update = the account itself), customer-user-accesses,
customer-user-access-invitations, customer-client-links (manager
side), customer-manager-links (client side; action move),
customer-labels (label MCC children), product-links +
product-link-invitations (Merchant Center / GA4 / Hotel Center —
update ACCEPTED|REJECTED answers incoming invitations), and billing:
billing-setups, account-budget-proposals, invoices,
payments-accounts.
- Experiments: experiments (create shell; action schedule|promote|end|
graduate), experiment-arms.
- Bulk: batch-jobs (create -> action add_operations with mixed
mutateOperations -> action run -> poll query -> ?job= results).

Cross-cutting: money/bids are in MICROS (1,000,000 = 1 unit of account
currency). Pause/enable anything via update {status:"PAUSED"|"ENABLED"}.
validate_only:true dry-runs any mutate without applying it.
update_mask overrides the auto-derived mask (derived recursively from
the fields you send, so nested objects mask only their set leaf paths).
partial_failure is accepted where Google supports it.

Authentication. The connector OAuth establishes which endpointr customer
you are. This uses its OWN vault slot (google-ads) — separate from the
google slot used by Tasks/Search Console/Analytics, so consent for one
never implicitly grants the other. Store a refresh-triplet once via
PUT /v1/credentials/google-ads {client_id, client_secret, refresh_token}
and endpointr mints short-lived access_tokens on every call — or click
"Connect Google Ads" on the customer's admin page to run the consent flow
and have refresh_token written automatically (never type it by hand).
Alternatively pass oauth_token (a fresh access_token) or the
refresh-triplet inline per-request (credential fields are stripped before
reaching Google). Required scope: https://www.googleapis.com/auth/adwords.

Beyond OAuth, every call ALSO needs:
- developer_token (REQUIRED) — issued once per Ads MANAGER account via
the Ads UI (Tools & Settings > API Center); never rotates. Store it in
the google-ads vault entry, or pass developer_token per-request.
- login_customer_id (optional) — the manager account's id, needed only
when you reach the target account THROUGH a manager rather than
owning it directly. Same hybrid resolution.

When a token is minted from the vault, the new access_token is surfaced in
the response as refreshed_access_token so clients can cache it (~1h TTL).

Tool arguments mirror the HTTP request body / path id / query string.
create/update tools accept an open body object — the schema lists
documented fields, but bodies are forwarded to Google verbatim, so the
full v25 request shape of every resource is supported. Over MCP there is
no query string: customer_id rides in the query arg on query verbs,
in the body on create/update, and inside the composite/full-resource
id on delete.

This connector is a Google Tag Manager API (v2) relay exposed through
endpointr: full container management — accounts, containers, workspaces,
tags, triggers, variables, built-in variables, folders, environments, and
versioning INCLUDING publish-to-live. Each tool mirrors one REST endpoint
under /v1/tagmanager/*. Tool names follow:
endpointr_tagmanager_gtm_<resource>_<verb>
where verb is one of: list (GET collection), query (GET with query params),
get (GET by id), create (POST), update (PUT), delete (DELETE).

THE ID MODEL (read this first): GTM addresses everything by a nested path
(accounts/{a}/containers/{c}/workspaces/{w}/tags/{t}). Collection verbs
(query/create) take the parent ids as account_id / container_id /
workspace_id (query arg on reads, body on writes). get/update/delete take
the target as id — either the full GTM path every resource carries, or
the colon composite of the same ids in order: a container is
accountId:containerId, a workspace accountId:containerId:workspaceId, a
tag/trigger/variable/folder appends its own id as the 4th part.

Typical flow: gtm-accounts list -> gtm-containers query ?account_id (the
numeric containerId is what the other tools take; publicId is the
GTM-XXXXXXX snippet id) -> gtm-workspaces query (find the Default
Workspace) -> create/edit tags, triggers and variables in that workspace ->
gtm-workspaces create {action:'create_version'} (snapshot) -> gtm-versions
create {action:'publish', version_id} (LIVE on the site).

Resources:
- gtm-accounts list = every GTM account the grant reaches (start
here); get by accountId. Read-only.
- gtm-containers query ?account_id = list; or look one up from its
public snippet id with ?destination_id=GTM-XXXXXXX (no
account needed). create needs {account_id, name,
usageContext:["web"]}. delete is IRREVERSIBLE.
- gtm-workspaces the editable draft layer every tag/trigger/variable
write happens in. create also folds the sub-methods:
{action:'create_version'} snapshots the workspace into
a version (response carries containerVersion.
containerVersionId), {action:'sync'} pulls
latest-version changes in.
- gtm-tags CRUD inside a workspace ({…ids, name, type,
parameter[], firingTriggerId[]}). Common types:
googtag (Google tag/GA4), gaawe (GA4 event), html
(custom HTML), awct (Ads conversion).
- gtm-triggers CRUD; types pageview, click, linkClick, customEvent,
scrollDepth, … A trigger's triggerId feeds tags'
firingTriggerId.
- gtm-variables user-defined variables CRUD; types v (data layer), c
(constant), jsm (custom JS), u (URL), … Reference as
{{Name}} from tag/trigger parameters.
- gtm-built-in-variables the one-click toggles (Page URL, Click
Classes, …): query = enabled ones, create = enable
({…ids, type:"pageUrl" | [types…]}), delete = disable
(id accountId:containerId:workspaceId:type).
- gtm-folders workspace organisation CRUD; file an entity by setting
parentFolderId on the entity itself.
- gtm-versions query ?account_id&container_id = version HEADERS;
get by a:c:versionId — or the specials a:c:live
(the published version) and a:c:latest. create is
action-only: {action:'publish'|'undelete'|'set_latest',
account_id, container_id, version_id} — PUBLISH PUSHES
LIVE. update renames; delete trashes a version.
- gtm-environments live/latest plus custom preview/staging environments
(auth codes + preview links). Full CRUD.

Cross-cutting: every response wraps the GTM payload as {data: …}. Mutable
resources carry a fingerprint — pass it on update/publish for
optimistic-concurrency protection (omitted = last write wins). Writes land
in a workspace and are NOT live until a version is created and published.

MCP note: there is no query string over MCP, so parent ids ride the query
arg on query verbs, the body on create/update, and the composite/full-path
id on get/delete.

Authentication. The connector OAuth establishes which endpointr customer
you are. This uses its OWN vault slot (google-tagmanager) — separate from
the google slot used by Tasks/Search Console/Analytics, so Tag Manager's
write+publish consent is granted independently. Store a refresh-triplet
once via PUT /v1/credentials/google-tagmanager {client_id, client_secret,
refresh_token} and endpointr mints short-lived access_tokens on every call
— or click "Connect Google Tag Manager" on the customer's admin page to run
the consent flow and have refresh_token written automatically. Alternatively
pass oauth_token (a fresh access_token) or the refresh-triplet inline
per-request (credential fields are stripped before reaching Google).
Scopes: tagmanager.readonly, tagmanager.edit.containers,
tagmanager.edit.containerversions, tagmanager.publish,
tagmanager.delete.containers.

When a token is minted from the vault, the new access_token is surfaced in
the response as refreshed_access_token so clients can cache it (~1h TTL).

Tool arguments mirror the HTTP request body / path id / query string.
create/update tools accept an open body object — the schema lists
documented fields, but bodies are forwarded to Google verbatim, so the full
v2 request shape of every resource is supported.

This connector is a Reddit Ads API (v3, https://ads-api.reddit.com/api/v3)
relay exposed through endpointr: full campaign management, audiences,
creatives, conversions (CAPI), product catalogs, targeting reference data,
and reporting. Each tool mirrors one or more REST endpoints under
/v1/redditads/*. Tool names follow:
endpointr_redditads_reddit_<resource>_<verb>
where verb is one of: list (GET collection), query (GET with query params),
get (GET by id), create (POST), update (PATCH upstream), delete (DELETE).

Id chain (chain these): reddit-me list (smoke test) -> reddit-businesses
list (business_id) -> reddit-ad-accounts query ?business_id (ad_account_id)
-> campaigns / ad-groups / ads / custom-audiences / saved-audiences /
lead-gen-forms / reports, all keyed by ad_account_id. Posts, structured
posts and creative assets hang off reddit-profiles (profile_id, from
?ad_account_id or ?business_id). Product feeds/sets/products hang off
reddit-product-catalogs (catalog_id, from ?business_id). Campaign create
also needs a funding_instrument_id (reddit-funding-instruments).

Campaign build order: campaign create (objective, funding_instrument_id)
-> ad-group create (campaign_id + targeting/bid; validate targeting values
with reddit-targeting first) -> post create (profile_id) -> ad create
(ad_group_id + post_id). Start everything configured_status=PAUSED and
flip to ACTIVE when ready.

Reddit API shapes the relay smooths over:
- Write bodies are auto-wrapped in Reddit's {"data": {...}} envelope —
pass flat fields (an explicit data key is forwarded as-is).
- Updates are PATCH upstream; send only the fields to change. There is
NO delete for campaigns/ad groups/ads — archive/pause via
update {configured_status: PAUSED|ARCHIVED}.
- Lists paginate via page.size/page.token (aliases page_size/
page_token accepted) and return pagination.next_url — pass that URL
back as a next_url query field to fetch the next page.
- Money is in MICROCURRENCY (1,000,000 = 1 unit of the account
currency); timestamps are ISO 8601 UTC.
- MCP note: parent ids ride the query arg on query verbs and the
body on create; get/update/delete take only the object id — Reddit
ids are globally unique, so no composite ids anywhere.

Authentication. The connector OAuth establishes which endpointr customer
you are. This uses its OWN vault slot (reddit-ads). Store client_id +
client_secret once and run the admin page's "Connect Reddit Ads" consent
flow to mint the refresh_token automatically — or PUT the full triplet via
PUT /v1/credentials/reddit-ads {client_id, client_secret, refresh_token}.
endpointr exchanges the triplet for a short-lived (~24h) access_token on
every call and persists any rotated refresh_token. Alternatively pass
oauth_token (a fresh access_token) or the refresh-triplet inline
per-request (credential fields are stripped before reaching Reddit). An
optional vault user_agent overrides the descriptive User-Agent endpointr
sends (Reddit blocks generic UAs). Scopes: adsread adsedit adsconversions
adsdatadeletion. Reads work for any authorized app; CREATE/EDIT endpoints
additionally require Reddit's Ads API developer approval.

When a token is minted from the vault, the new access_token is surfaced in
the response as refreshed_access_token so clients can cache it (~24h TTL).

Tool arguments mirror the HTTP request body / path id / query string. Most
create/update tools accept an open body object — the schema lists
documented fields, but handlers forward additional keys to Reddit verbatim.

This connector is a SendMails.io relay (a hosted Acelle Mail —
https://app.sendmails.io/api/v1) exposed through endpointr: newsletter
campaigns, mail lists, and subscribers. Each tool mirrors one REST endpoint
under /v1/sendmails/*. Tool names follow:
endpointr_sendmails_sendmails_<resource>_<verb>
where verb is one of: list (GET collection, no params), query (GET with
params), get (GET by uid), create (POST), update (PATCH upstream), delete.

Typical newsletter flow: lists list (pick/create a list_uid) -> subscribers
create (add recipients) -> campaigns create (the newsletter: subject, html,
from) -> campaigns create {action:'run', uid} (start sending) -> campaigns
get (delivery statistics).

Resources:
- lists list = all mail lists, NO parameters — the id source: each
result's uid is the list_uid subscribers + campaigns
need. get by uid. create needs name, from_email, from_name
+ a contact block (company, address_1, city, zip, country_id,
email, phone?). Fold {action:'add_field', uid, type, label,
tag} to add a custom subscriber field. delete by uid.
- subscribers FULL CRUD (create/update/delete all write — not read-only).
query = subscribers on a list (REQUIRES list_uid; filters:
per_page, page, keyword?). get by uid. create adds one
({list_uid, EMAIL, FIRST_NAME?, LAST_NAME?, ...}). Fields are
keyed by their Acelle identifier (the uppercase field key:
EMAIL, FIRST_NAME, custom fields). Label a subscriber with the
built-in tag field — SINGULAR, a comma-separated STRING
(e.g. "vip,newsletter"); there is no tags array, and sending
tags is silently ignored. status field = subscribed|
unsubscribed. Fold {action:'subscribe'|'unsubscribe', uid} to
flip status. update by uid (PATCH, send only changed fields);
delete by uid.
- campaigns THE NEWSLETTER SURFACE. list = all campaigns, NO parameters
(each result's uid is the campaign id). get by uid returns
details + statistics (sent/open/click/bounce). create a
draft: {name, list_uid, subject, from_email, from_name,
reply_to, html, plain?, track_open?/track_click? ('yes'/'no'),
run_at? ('Y-m-d H:i:s' to schedule)}. Fold
{action:'run'|'pause'|'resume', uid} for the send lifecycle.
update a draft by uid; delete by uid.

Authentication. The connector OAuth establishes which endpointr customer you
are. The upstream api_token is resolved per customer from the vault — store
it once via PUT /v1/credentials/sendmails {api_token:"…"} (from the
SendMails.io dashboard, Account > API). Vault-only.

Tool arguments mirror the HTTP request body / path id / query string; extra
fields are forwarded to SendMails verbatim.

This connector is an Encharge.io relay (https://api.encharge.io/v1) exposed
through endpointr: people, tags, fields, segments, webhooks, account. Each
tool mirrors one REST endpoint under /v1/encharge/*. Tool names follow:
endpointr_encharge_encharge_<resource>_<verb>
where verb is one of: list (GET, no params), query (GET with params),
create (POST), update (PATCH upstream), delete (DELETE).

THE OUTREACH MODEL — read this first: Encharge's public API has NO
campaign/newsletter endpoints. Emails are sent by Flows built in the
Encharge UI; the API's job is getting people INTO those flows. To send
outreach: people create (upsert the person) -> tags create ({tag:"…",
email}) — a Flow triggered by that tag sends the email sequence.

Resources:
- account list = account info (peopleCount, timezone, …), NO parameters.
The connector smoke test — call it first.
- people query = fetch specific people by identifier (email / user_id /
id; emails comma-list for several; raw people array for
mixed identifiers). create = UPSERT one person object or a
people array (identified by email/userId/id; any extra keys
become field values). Fold {action:'unsubscribe', email} to
stop all email to a person. delete by id (the person's email
or Encharge id; add force=true for GDPR wipe — else archives).
- tags create = add tag(s) ({tag:"a,b", email}) — THE outreach
trigger. Fold {action:'remove', tag, email} to untag. Tags are
free strings; no upstream list — a person's current tags are on
their tags field via people query.
- fields list = all person fields, NO parameters (the field name is
the id). create ({name, type, title?} or a fields array),
update by fieldName, delete by fieldName.
- segments list = all segments, NO parameters (id source). query = people
in one segment (REQUIRES segment_id; limit/offset/attributes/
sort/order).
- webhooks create = subscribe to Encharge events ({eventType, targetUrl};
eventTypes: newUser, updatedUser, unsubscribedUser,
added-tag-<TAG>, removed-tag-<TAG>). delete by the numeric id
FROM THE CREATE RESPONSE — no upstream list (keep the id).

Authentication. The connector OAuth establishes which endpointr customer you
are. The upstream API key is resolved per customer from the vault — store it
once via PUT /v1/credentials/encharge {api_key:"…"} (Encharge > Settings >
Account). Sent as the X-Encharge-Token header. Vault-only.

Tool arguments mirror the HTTP request body / path id / query string; extra
person keys are forwarded to Encharge verbatim (they become field values).

This connector is a Sendr.io relay (https://api.sendr.io) exposed through
endpointr: signal-driven outreach — contact sheets feeding campaign
sequences, personalized pages (GIF / dynamic audio / lip-sync video), and a
unified reply inbox. Each tool mirrors one REST endpoint under /v1/sendr/*.
Tool names follow:
endpointr_sendr_sendr_<resource>_<verb>
where verb is one of: list (GET, no params), query (GET with params),
get (GET by id), create (POST), update (PATCH upstream), delete.

THE MODEL: a campaign runs on a SHEET of contacts. Campaigns are built in
the Sendr app and are READ-ONLY via the API — you add contacts by adding
ROWS to the campaign's sheet. Replies land in the INBOX. Personalized
pages are generated from PAGE TEMPLATES.

Resources & id chains:
- seat list = API-user/workspace info, NO parameters. The
connector smoke test — call it first. Also the seat id
source for inbox assignment.
- sheets list (no params) / query (offset, limit, name,
campaignId) / get. Each sheet's id feeds sheet-columns
and sheet-rows.
- sheet-columns query REQUIRES sheet_id — the sheet's field schema;
column names are the keys sheet-rows accepts.
- sheet-rows create REQUIRES sheet_id + the row fields (column
names) — HOW YOU ADD A CONTACT to a campaign.
- campaigns list (no params) / query (page, limit, search, status
DRAFT|ACTIVE|PAUSED) / get. READ-ONLY upstream — no
create/pause via API. Each campaign carries its
sheetId (feed sheet-rows to add contacts).
- page-templates list = templates (no params; the templateId source);
get = a template's VARIABLE TAGS (the keys for
variablesValues).
- pages create = generate a personalized page ({templateId,
variablesValues, gifSource?, videoBackgroundUrl?,
attributes?, webhookUrl?}) -> {pageId, pageUrl}. get by
pageId/slug = status (pending|done|failed) + generated
assets. Poll get until done, or use webhooks.
- dynamic-audio create = queue personalized audio ({audioUrl,
targetWord, replacementWord}) -> jobId.
- video create = queue personalized video (same + videoUrl;
mode merge|lipsync|video_only) -> jobId.
- webhooks list = workspace webhooks (no params). Sendr keys
webhooks BY URL, so mutations fold onto create:
create {name, url, events?} | {action:'update', url, …}
| {action:'delete', url} | {action:'toggle', url,
enabled} | {action:'reveal_secret', url}. Events:
page:pending/done/failed, engagement:page_view/
audio_play/video_play/button_click/meeting_booked, ….
- inbox list = 25 latest reply threads (no params) / query
(search, status unread|deleted, channels, campaign_ids,
tag_ids, starred, cursor, limit) / get by threadId.
create = act via action: send {thread_id, body} (reply),
read/unread, star/unstar, tag/untag {thread_id, tag_id},
delete/restore {thread_ids[]}, assign {thread_ids[],
seat_id}.
- inbox-messages query REQUIRES thread_id (+cursor/limit) = the thread's
messages; add message_id = attachment list; add
attachment_id = download (base64 + mime).
- inbox-tags list/query/create/update/delete — the tag_id source.
- inbox-campaigns list = campaigns that have inbox threads (the
campaign_ids filter source).
- analyze-website create {url} = about text + generated buyer personas.

Authentication. The connector OAuth establishes which endpointr customer you
are. The upstream API key is resolved per customer from the vault — store it
once via PUT /v1/credentials/sendr {api_key:"…"} (generate it at
app.sendr.io > Settings > API keys). Sent as the X-API-Key header. Vault-only.

Tool arguments mirror the HTTP request body / path id / query string; extra
fields are forwarded to Sendr verbatim.

This connector is a LeadShark relay (https://apex.leadshark.io) exposed through
endpointr: LinkedIn enrichment, post-engagement AUTOMATIONS, lead capture,
scheduled posts, lead-magnet pages/links, engagement signals, and webhooks.
Each tool mirrors one REST endpoint under /v1/social/leadshark-*. Tool names:
endpointr_social_leadshark_<resource>_<verb>
where verb is one of: list (GET, no params), query (GET with params),
get (GET by id), create (POST), update (PUT), delete (DELETE).

THE AUTOMATION MODEL (the headline feature): an automation watches ONE
LinkedIn post and DMs/replies/connects with people who comment matching
keywords. To create one you need the post's URN + share URL, which come from
the posts tool:
1. leadshark-posts query -> pick a post; copy item.post_id (a URN like
urn:li:activity:7150…) and item.share_url.
2. leadshark-automations create {name, post_id:<URN>, linkedin_post_url:
<share_url>, keywords, dm_template, …}.
Use the FULL URN exactly — the numeric tail alone creates the row but
engagement won't bind. Pass only {name, post_id, linkedin_post_url} for a
webhook-only automation (comments stream to your webhooks; no LeadShark-side
actions). Toggle Running/Paused/Stopped via leadshark-automation-status.

Resources & id chains:
- enrich-person / enrich-company : query = enrich a LinkedIn profile/company
(real profile view; soft cap ~200-250/day).
- linkedin-search : create = LinkedIn people/company search.
- posts : query = your (or anyone's, via linkedin_id) LinkedIn
posts. THE id source for automations (post_id + share_url)
and the engagement tools (post_id URN).
- automations : list/query/get/create/update/delete. create binds to a
post (see above). automation-status update flips status.
automation-templates query = reusable templates; each id
is a template_id for scheduled-posts.
- leads : query = captured leads (email + ICP score when present).
- bookmarks / bookmark-tags : save LinkedIn profiles with tags/notes.
- scheduled-posts : list/create/update/delete. create {content,
scheduled_time} (15 min-90 days out) with an optional
automation pre-automation that activates on publish —
it accepts page_id (links_enabled:true) or template_id.
- post-stats : query = post metrics; summary=true = lifetime totals
(Apex). dashboard-activity query = activity rollups.
- discover (Apex): fresh lead-magnet posts to engage.
- signals (Apex) : signals = ranked hot leads; signal-events = raw events
(type + since/until or since_captured/until_captured).
- engagement (Pro+): post-reactions / post-comments / post-reposts REQUIRE
post_id (URN from posts). profile-viewers = Apex + Premium.
- links (Pro+) : list/get/create/delete tracking links; each slug feeds
link-analytics and link-events. Attach a page via page_id.
- pages (Pro+) : quiz lead-magnet pages CRUD; each id is a page_id for
links and pre-automations; page-stats / page-responses /
page-emails REQUIRE page_id.
- webhooks (Pro) : CRUD + webhook-test. event_types new_comment /
email_captured / lead_sent (Pro) + new_profile_visit /
new_like (Apex only). HMAC-SHA256 signed; secret shown once.

Tier gating (Pro / Pro+ / Apex) is enforced by LeadShark — a call outside your
plan returns 403 with an explanatory body. Rate limits: 250/hr, 1000/day,
100/min (429 on exceed — back off).

Authentication. The connector OAuth establishes which endpointr customer you
are. The upstream key is resolved per customer from the vault — store it once
via PUT /v1/credentials/leadshark {api_key:"…"} (LeadShark Settings → API
Access). Sent as the x-api-key header. You may also pass api_key inline in
any tool's body/query for per-request passthrough; it is stripped before the
request reaches LeadShark.

This connector is a PayPal REST API relay (https://api-m.paypal.com) exposed
through endpointr, scoped to READ-ONLY money reporting — invoices,
subscriptions, balance, and income. No write/refund/charge operations. Each
tool mirrors one PayPal endpoint. Tool names follow:
endpointr_payments_paypal_<resource>_<verb>
where verb is: list (GET collection / singleton), query (GET/search with
params), get (GET by id).

Resources:
- overview list = a computed snapshot in ONE call: balances +
invoices bucketed PAID / OUTSTANDING / OVERDUE + gross
income over the last 30 days, grouped per currency. Start
here for "how are we doing".
- invoices query = list invoices, or SEARCH when you pass filters
(status e.g. PAID|SENT|UNPAID|PAYMENT_PENDING|
MARKED_AS_PAID|PARTIALLY_PAID|CANCELLED, invoice_date_range,
due_date_range, recipient_email, total_amount_range,
plus page/page_size). get = one invoice by id. PayPal has
no "overdue" status — overdue = outstanding past its due date
(filter due_date_range, or read overview.invoices.overdue).
- transactions query = Transaction Search — the true "overall income"
source (every payment received, not just invoiced).
REQUIRES start_date+end_date (RFC3339), max 31 days apart;
page by month for longer ranges.
- balance list = current available money on the account, per currency.
- plans query = billing plans (the NAMED recurring products). This
is how you "search subscriptions by name/description" — pass
name/description (filtered client-side within the fetched
page). get = one plan by id (P-…).
- subscriptions get = one subscription by id (I-…): status, plan_id,
subscriber, next billing, last payment, outstanding balance.
PayPal has NO list/search for subscriptions — find the plan
by name via plans, read a subscriber's sub by its I-… id.
- accounts list = the configured PayPal account labels (see below).

balance, transactions, and overview's balance/income need the PayPal REST
app to have the "Transaction Search" feature enabled; data can lag live by ~3h.

Authentication. The connector OAuth establishes which endpointr customer you
are. The upstream PayPal credential is resolved per customer from the vault —
store it once via PUT /v1/credentials/paypal
{client_id, client_secret, mode} (mode = live|sandbox; from a REST API app at
developer.paypal.com). The relay exchanges it for a short-lived access_token
(client-credentials) and caches it — you never handle tokens. Vault-only:
client_id/client_secret are never accepted per-request.

Multiple PayPal accounts. One login can hold several accounts, each stored
under paypal:<label> (e.g. paypal:conzent). EVERY tool accepts an optional
top-level account argument naming which to target; when more than one is
configured it is REQUIRED (a call that omits it is rejected with the list of
labels). Call the accounts-list tool to see them. A single unlabelled paypal
credential lets you omit account.

Money values are decimal major units with a currency code. Tool arguments
mirror the HTTP query string / path id.

This connector is a Stripe API relay (https://api.stripe.com/v1) exposed
through endpointr, scoped to the core payments resources. Each tool mirrors one
Stripe REST endpoint. Tool names follow:
endpointr_payments_stripe_<resource>_<verb>
where verb is one of: list (GET collection), query (GET with query params),
get (GET by id), create (POST), update (POST upstream), delete (DELETE).

Resources: payment-intents, charges, customers, payment-methods, products,
prices, subscriptions, invoices, refunds, payouts, balance, balance-transactions,
checkout-sessions, setup-intents, events, overview, accounts.

The overview resource is a computed business-health snapshot (MRR, ARR, active
subscriptions & customers, new subs and cancellations over 1/7/30 days, refunds,
monthly churn, ARPU, LTV) grouped per currency — call
endpointr_payments_stripe_overview_list.

Multiple Stripe accounts. One login can hold several Stripe accounts (e.g. two
companies), each stored under its own credential stripe:<label> via
PUT /v1/credentials/stripe:<label> {api_key:'sk_live_…'} (e.g. stripe:rexultz,
stripe:conzent). EVERY tool accepts an optional top-level account argument
naming which account to target, e.g.
endpointr_payments_stripe_overview_list {account:'rexultz'} or
endpointr_payments_stripe_subscriptions_query {account:'conzent', query:{status:'active'}}.
When more than one account is configured, account is REQUIRED — a call that
omits it is rejected with the list of valid labels. Call
endpointr_payments_stripe_accounts_list to see the configured labels. If only a
single unlabelled stripe credential exists, account may be omitted.

Stripe uses POST for both create and update, and it has non-CRUD verbs
(confirm, capture, cancel, finalize, pay, send, void, attach, detach, reverse,
expire). Those are folded onto the create tool via an action field plus the
target id — e.g. confirm a PaymentIntent with
create {action:'confirm', id:'pi_…', payment_method:'pm_…'}, finalize an
invoice with create {action:'finalize', id:'in_…'}, attach a PaymentMethod
with create {action:'attach', id:'pm_…', customer:'cus_…'}. Without an
action, create POSTs to the bare collection to create a new resource. Each
tool's description lists its available actions.

Amounts are in the currency's smallest unit (e.g. 1099 = $10.99; zero-decimal
currencies like JPY use the whole number). Nested fields use Stripe's object
shape in the body/query args (e.g. {metadata:{order_id:'…'}},
{items:[{price:'price_…'}]}) — the relay serialises them to Stripe's
bracket form.

Authentication. The connector OAuth establishes which endpointr customer you
are. The upstream Stripe secret key is resolved per customer from the credential
vault — store it once via PUT /v1/credentials/stripe {api_key:'sk_live_…'}
(test mode: sk_test_…). Vault-only: the secret key is never accepted
per-request.

Tool arguments mirror the HTTP request body / path id / query string. Most
create/update tools accept an open body object — the schema lists documented
fields, but handlers forward additional keys to Stripe verbatim.

This connector is an Easifynow relay (https://api.easifynow.com) exposed through
endpointr. Easifynow is a linkbuilding platform: a catalogue of publisher
domains and an endpoint that publishes an article with links on one of them.
Each tool mirrors one route under /v1/linkbuilding/easifynow-*. Tool names:
endpointr_linkbuilding_easifynow_<resource>_<verb>
where verb is one of: list (GET, no params), query (GET with params),
get (GET by id), create (POST), delete (DELETE).

PUBLISHING IS PUBLIC AND COSTS MONEY. articles create without dry_run puts an
article live on a third-party website and spends one credit. Show the user the
domain, title, links and anchor texts and get a clear yes before calling it.
Always run it with dry_run:true first.

Typical flow for one client site:
1. account list credits left (and proves the login works)
2. pick query {target} the best domains for the client site, each with
its numbers and a reason. Domains that already
link to the target are excluded.
3. domain-categories get the chosen domain's WordPress categories; one
wp_category_id becomes selected_category_id
4. Write the article in the domain's language (a .dk domain needs Danish):
at least 500 words, at most 3 external links each with anchor text, no
script/iframe/hidden text. Mostly branded or natural anchors.
5. articles create {..., dry_run:true} local + Easifynow validation,
nothing published, no credit spent
6. articles create {...} publish, after the user approves
7. articles get <submission_id> app_status, and wp_post_url once live

Resources:
- account list = credits, submission stats, link statistics.
- tlds list = country TLDs the account can publish on.
- domains list = first 200 domains by traffic; query = the
catalogue with filters (tld, id_category,
exclude_linking_to, sort_by trafik|dr|ref_domains, ...).
trafik is monthly traffic, navn the site name.
- pick query = ranked domains for a target site.
- domain-categories get = a domain's categories (by domain id).
- articles list/query = submission history; get = one submission;
create = publish (or dry_run, or action:'update' to
change a live article); delete = trash a live article.

The featured image is required: pass image_url (public https, at least
800x400 px). The relay fetches it and brings it under Easifynow's 1 MB cap.

Authentication. The connector OAuth establishes which endpointr customer you
are. Easifynow signs in with email + password (no API key); store them once via
PUT /v1/credentials/easifynow {email, password}. The relay logs in, caches the
token and renews it, so you never handle tokens.

Issue a JWT from a valid api_key.

Body:
{ "api_key": "…" }

On success, this request auto-captures the JWT into the collection variable token, so every subsequent request gets Authorization: Bearer {{token}} automatically.

Introspect the current token without erroring on edge cases.

Returns {valid, reason, jti, expires_in, expired, revoked, user}. reason is one of:
- null — token is good
- missing — no Bearer header
- expired — past exp
- revoked — jti in revoked_tokens (another device called DELETE)
- bad_signature / malformed — not our token

Use this as a pre-flight: if expires_in < 60, call PATCH to rotate; if revoked, re-exchange your api_key with POST.

Tip: You can usually skip this — the JWT is self-describing. Base64-decode the middle segment client-side and read exp directly. The one thing only this endpoint can tell you is *revocation*.

Rotate the current token. Revokes the presented jti and issues a fresh one.

Revoke the current token (logout).

Upload your PEM public key (≥ 2048 bits).

Private keys MUST NOT be sent.

Return the stored public key for the authenticated customer.

Check whether creds exist for a service (does not return values).

:service — e.g. openai, anthropic, openrouter, claude-cli, openai-cli, stripe, mailchimp, ipregistry …

Store the JSON credential map for a service. Body is the map itself.

AI providers — auto-appended to the customer's provider-priority list on save (admin can reorder via /admin/customers/{id} → Provider priority):
- openai: { "api_key": "sk-…", "organization": "org-…" } (organization optional)
- anthropic: { "api_key": "sk-ant-…" }
- openrouter: { "api_key": "sk-or-…", "referer": "https://yourapp.com", "app_title": "YourApp" } (referer + app_title optional, used for OpenRouter's app rankings)
- claude-cli: { "oauth_token": "sk-ant-oat01-…" } (from claude setup-token)
- openai-cli: { "api_key": "sk-…" }

Other services:
- stripe: { "api_key": "sk_live_…", "webhook_secret": "whsec_…" } (webhook_secret optional)
- mailchimp: { "api_key": "…-usX", "list_id": "abc" } (list_id optional)
- ipregistry: { "api_key": "…" }

Remove stored creds for a service. If the service is an AI provider in the priority list, it is also removed from priority.

List the caller's vault entries. Returns names and updated_at only — values stay sealed. Use GET /v1/vault/:name to fetch one.

Fetch the decrypted JSON object stored at :name. Unlike /v1/credentials/:service, this returns the actual values — that's the point of the vault.

Use case. Your SaaS calls this at runtime to retrieve secrets (Amazon SES SMTP, ShortPixel keys, etc.) instead of hardcoding them. Rotate by editing the vault entry once in /admin/customers/{id} → Vault; every app picks up the new value on its next fetch.

Naming. :name is customer-chosen, lowercase: [a-z0-9][a-z0-9_-]{0,63}. Pick something descriptive (e.g. ses-prod, shortpixel, mailgun-eu).

Response: { "name": "ses-prod", "data": { …whatever you stored… } }. 404 if the name is unknown for this customer.

Create or replace the vault entry at :name. Body is the JSON object to store — any shape you like, since you'll be reading it back yourself.

Example — Amazon SES SMTP:

{
  "smtp_host": "email-smtp.us-east-1.amazonaws.com",
  "smtp_port": 587,
  "smtp_user": "AKIA…",
  "smtp_pass": "BJ…"
}

Example — ShortPixel:

{ "api_key": "…" }

Existing entries are overwritten in place. Encrypted at rest with the same XSalsa20-Poly1305 key as /v1/credentials/:service.

Remove the vault entry at :name.

Text chat across providers. Canonical body is the minimum that works when you've stored credentials for at least one provider via PUT /v1/credentials/:service — Endpointr walks the customer's priority list, picks the first survivor, and falls over to the next on 5xx / 401 / 403 / 429.

Provider selection. provider is optional. Omit it to use the priority list (set under /admin/customers/{id} → Provider priority). Pass it explicitly to pin one provider with no failover. Valid values: openai, anthropic, openrouter, claude-cli, openai-cli.

Credentials. Resolution order:
1. Per-request override in the body — oauth_token (for claude-cli) or api_key (for openai-cli). API providers have no body override; use stored creds.
2. Stored cred via PUT /v1/credentials/:service. Schemas:
- openai → {api_key, organization?}
- anthropic → {api_key}
- openrouter → {api_key, referer?, app_title?}
- claude-cli → {oauth_token}
- openai-cli → {api_key}
3. Server-wide env (CLAUDE_CODE_OAUTH_TOKEN, codex login state) — last resort.

Body shape. Send either prompt (string) or messages: [{role, content}, ...]. system is appended to the message list as a system role. json: true forces JSON output (provider permitting).

Sampling controls (temperature, max_tokens, top_p, stop) work for openai, anthropic, openrouter. The CLI providers ignore them — the underlying binaries don't expose those flags. If you need sampling control, pin provider: openai or provider: anthropic.

Other example bodies.

Explicit OpenAI with sampling controls:

{"provider":"openai","model":"gpt-4o-mini","temperature":0.2,"max_tokens":150,"prompt":"Summarize the goal of OAuth2 in one sentence."}

Explicit Anthropic via API key (set anthropic.api_key once via /v1/credentials/anthropic; no body creds needed):

{"provider":"anthropic","model":"claude-sonnet-4-6","prompt":"Why is HTTPS preferred over HTTP?"}

Claude-CLI subscription with body-supplied token:

{"provider":"claude-cli","model":"claude-sonnet-4-6","oauth_token":"{{claude_oauth_token}}","system":"You are concise.","prompt":"Write one sentence about rain."}

Messages array with multi-turn history:

{"messages":[{"role":"system","content":"You are concise."},{"role":"user","content":"What's 2+2?"},{"role":"assistant","content":"4."},{"role":"user","content":"And times 3?"}]}

Force JSON output:

{"prompt":"Return {\"colors\": [...]} with three primary colors.","json":true}

Minimal body: {"prompt":"Write one sentence about rain."}

Same shape as /v1/ai/chat, but proxies the provider's native SSE stream back to you. Returns text/event-stream.

No failover for streaming — once SSE headers are out, you can't switch providers mid-flight. The first qualifying candidate handles the stream; mid-stream errors surface as SSE error frames.

Supported: claude-cli, anthropic, openai, openrouter. openai-cli does not support streaming (501).

Tip. Postman shows the full response after it completes; use curl -N in a terminal to see chunks live.

Other example bodies.

Explicit OpenAI:

{"provider":"openai","model":"gpt-4o-mini","max_tokens":200,"prompt":"Write a haiku about rain."}

Claude-CLI with body-supplied token:

{"provider":"claude-cli","model":"claude-sonnet-4-6","oauth_token":"{{claude_oauth_token}}","prompt":"Write a haiku about rain.","max_tokens":200}

Minimal body: {"prompt":"Write a haiku about rain.","max_tokens":200}

Streaming twin of POST /v1/ai/conversation. Same per-customer memory + Elasticsearch retrieval pipeline and narration-style system prompt — but the assistant reply is delivered as Server-Sent Events for low-latency voice / UI use cases.

Wire format (Content-Type: text/event-stream):
1. event: endpointr_retrieval — retrieval status + hits, emitted before the model starts.
2. Provider-native SSE frames — Anthropic content_block_delta, OpenAI choices[].delta.content, or ClaudeCli stream-json.
3. event: endpointr_done — final conversation id + usage metadata after the stream ends.

Memory is loaded before any output, so memory failures surface as a normal JSON 4xx/5xx. Once the retrieval frame is on the wire, errors become SSE error frames rather than HTTP errors.

Body fields are identical to /v1/ai/conversation (prompt OR messages, optional provider/model/temperature/max_tokens/stop/oauth_token/api_key/system/retrieval/memory). stream is implied — stream: false is rejected (use the non-streaming endpoint instead). json: true is rejected (incompatible with conversational narration output).

Tip. Postman buffers SSE bodies — you'll see the full stream after the request ends. Use curl -N to watch frames live.

Minimal body: {"prompt":"How do I refund a charge?","retrieval":{"k":4}}

Conversational chat with server-side memory and per-customer Elasticsearch retrieval, tuned for narration / TTS / voice agents.

Unlike /v1/ai/chat, the response is plain spoken prose — no markdown, no bullet points, no headers. Think "two friends talking," not a chatbot dumping a formatted answer.

Memory scope. One thread per customer (the API-key holder identified by your JWT). No user_id to manage — your token *is* the identity. Thread isolation between customers is JWT-enforced.

Required. prompt OR messages (same shape as Chat). If both, messages wins.

Optional.
- provider, model, temperature, top_p, max_tokens, stop — passed through (same priority/failover as /v1/ai/chat).
- oauth_token / api_key — per-request credential override (same semantics as Chat).
- system — appended to (not replacing) the built-in narration prompt.
- retrieval — {enabled?: true, k?: 4, num_candidates?: 50, min_score?: null}. Set enabled: false to skip ES entirely.
- memory — {enabled?: true, reset?: false}. reset: true clears your history before this turn.

Rejected.
- json: true — incompatible with the conversational output style; use /v1/ai/chat.
- stream: true — not supported (memory persists after the full response).

Retrieval status (always answered; retrieval.status in response tells you what happened):
- ok — hits returned
- index_missing — no customer_{id}_documents index yet
- empty — index exists, no matching docs
- embedding_failed — fell back to BM25 only
- no_embed_provider — no provider with embed capability + creds; BM25-only fallback also unavailable
- error — ES network/cluster error
- disabled — caller passed retrieval.enabled: false or there was no user query to embed

Embeddings use OpenAI-compatible providers (openai, openrouter). Stored creds reused; no separate setup.

Memory cap. 30 messages or ~8000 estimated tokens, whichever hits first. Older turns drop off transparently.

Other example bodies.

Reset history mid-conversation:

{"prompt":"Let's start fresh — what's the weather like in Paris?","memory":{"reset":true}}

Disable retrieval (skip ES query, save 50-100ms):

{"prompt":"What's 2+2?","retrieval":{"enabled":false}}

With app-specific system guidance appended to the narration prompt:

{"prompt":"How do I refund?","system":"Always mention you're calling from EndpointrSupport.","retrieval":{"k":6}}

Minimal body: {"prompt":"How do I refund a charge?","retrieval":{"k":4}}

Generate images from a prompt. Default uses openai + gpt-image-1 (a small, square 1024x1024 image), so the canonical body needs only a prompt.

Supported providers: openai, openrouter. The Claude/Codex subscriptions don't include image generation — claude-cli, openai-cli, and anthropic return 501.

OpenAI models: gpt-image-1 (default), dall-e-3. Optional fields: size (1024x1024 | 1792x1024 | 1024x1792 for dall-e-3), n (1-10), quality, style, response_format (url | b64_json).

OpenRouter models (delivered via /chat/completions with modalities: ["image","text"] under the hood):
- google/gemini-2.5-flash-image-preview — "Nano Banana," fast & cheap (default if you specify provider: openrouter and omit model).
- google/gemini-3-pro-image-preview — "Nano Banana Pro," higher quality.

Reference images. Pass reference_images as an array (max 16) of:
- public https URLs (jpeg / png / gif / webp), or
- data:image/png;base64,... URIs, or
- bare base64 payloads (PNG assumed by content sniff).

When present, OpenAI is routed through /v1/images/edits (multipart upload — gpt-image-1 accepts up to 16 references; dall-e-2 accepts 1; dall-e-3 does not support edits). OpenRouter passes them as image_url content parts on the user message — Gemini Nano Banana / Pro use them as visual context for the generation.

Response. {provider, model, images: [{url}|{b64_json}]}. OpenAI follows your response_format. OpenRouter always returns b64_json (data URIs are stripped server-side).

Other example bodies.

Explicit OpenAI with high quality + base64 response:

{"provider":"openai","model":"gpt-image-1","prompt":"A red fox in snow, photorealistic","size":"1024x1024","quality":"high","response_format":"b64_json"}

OpenRouter Gemini Nano Banana Pro:

{"provider":"openrouter","model":"google/gemini-3-pro-image-preview","prompt":"A red fox in snow, photorealistic"}

DALL-E 3 widescreen:

{"provider":"openai","model":"dall-e-3","prompt":"A futuristic cityscape at dusk","size":"1792x1024"}

Gemini Nano Banana with two reference images (style transfer):

{"provider":"openrouter","model":"google/gemini-2.5-flash-image-preview","prompt":"Render the subject from image 1 in the painterly style of image 2.","reference_images":["https://example.com/subject.jpg","https://example.com/style.jpg"]}

OpenAI gpt-image-1 edit with reference (composite multiple inputs):

{"provider":"openai","model":"gpt-image-1","prompt":"Combine these into one cohesive scene at golden hour.","reference_images":["https://example.com/a.png","https://example.com/b.png"]}

Minimal body: {"prompt":"A red fox in snow, photorealistic"}

Lists the models available to the authenticated customer for a given provider.

provider is optional — falls back to the priority list with failover. Supported: anthropic, openai, openrouter. claude-cli and openai-cli (subscription providers) don't expose a model catalog endpoint and return 501.

Minimal query: {"provider":"openrouter"}

OpenAI-compatible chat/completions endpoint. Drop this in anywhere you'd point an OpenAI client (LangChain ChatOpenAI, the official openai SDK, n8n's *OpenAI* credential, etc.) and your customer api_key replaces the OpenAI key.

Path. Registered at both /v1/chat/completions (drop-in — n8n's default Base URL https://api.openai.com/v1 becomes https://api.endpointr.com/v1 with no path tweaking) and /v1/ai/completions (namespace match with the rest of /v1/ai/*). Same handler.

Auth. Authorization: Bearer <api_key> — the customer's raw api_key, not the JWT. No /v1/token exchange, no hourly refresh: n8n's OpenAI credential can't refresh on its own, so this endpoint uses the same flat-key model as OpenAI itself. SHA-256 hash lookup against customers.api_key_hash.

Response shape. Raw OpenAI envelope ({id, object, created, model, choices, usage}) — bypasses the standard Endpointr {httpCode, status, data, …} wrapper. Errors come back as {error: {message, type, code}}.

Model routing. Pick a model and the proxy picks the upstream:
- anthropic/<model> or bare claude-* → Anthropic API (uses the customer's vault anthropic.api_key). Full OpenAI ↔ Anthropic translation: messages, tools, tool_choice, tool_use blocks, system extraction, stop_reason mapping, usage field renaming.
- openai/<model> or bare gpt-* / o1-* / o3-* / o4-* → OpenAI API (vault openai.api_key). Near-passthrough — request/response barely touched.
- everything else → OpenRouter (vault openrouter.api_key). Passes the model string verbatim (google/gemini-2.5-flash, mistralai/mixtral-8x7b-instruct, etc.).

Missing creds for the resolved upstream → 401 with a clear message pointing at /admin/customers/{id} → service credentials.

Tool calling. Full support, required for n8n's AI Agent node. Send OpenAI-shape tools: [{type:"function", function:{name, description, parameters}}] and tool_choice — get back finish_reason: "tool_calls" with tool_calls[].function.arguments as a JSON-encoded string (this is what LangChain expects; do not parse it server-side). Continue the loop by sending a follow-up {role:"tool", tool_call_id, content} message.

Streaming. Set "stream": true to get back Content-Type: text/event-stream. Frames are chat.completion.chunk JSON terminated by data: [DONE]. For Anthropic this is full event-level translation (text deltas → delta.content, tool_use → delta.tool_calls[] with function.arguments arriving as concatenated string fragments — your client reassembles). Postman buffers SSE until end; use curl -N to watch live.

Accepted-but-ignored so n8n payloads don't trip a 400: logprobs, top_logprobs, n, seed, logit_bias, user, service_tier. Honored: model, messages, tools, tool_choice, stream, temperature, top_p, max_tokens, stop, response_format (OpenAI/OpenRouter only), presence_penalty / frequency_penalty (OpenAI/OpenRouter only).

Anthropic note. max_tokens is required upstream — we default to 4096 if you omit it.

Tool-call round-trip. Send tools + a prompt that should trigger one. Expect 200 with choices[0].finish_reason: "tool_calls", choices[0].message.content: null, and choices[0].message.tool_calls[0].function.arguments as a JSON-encoded string (e.g. "{\"city\":\"Copenhagen\"}").

Continue the conversation with a follow-up request adding two messages: the assistant turn you just received, then {role:"tool", tool_call_id:"<the id>", content:"15°C, light rain"}. The next response will have finish_reason: "stop" and the model's final answer.

Works identically on anthropic/*, openai/*, and OpenRouter-routed models — only the upstream wire differs.

Streaming variant. Same body as the non-streaming example with "stream": true. Returns Content-Type: text/event-stream and a sequence of data: {chat.completion.chunk} lines terminated by data: [DONE].

Postman buffers SSE bodies — you'll see the full stream after the request ends. To watch chunks live, use curl -N:

curl -N -X POST {{baseUrl}}/v1/chat/completions \
  -H "Authorization: Bearer {{api_key}}" \
  -H "Content-Type: application/json" \
  -d '{"model":"anthropic/claude-sonnet-4-6","messages":[{"role":"user","content":"Count from 1 to 5"}],"stream":true,"max_tokens":50}'

Same handler as POST /v1/chat/completions — registered at this path too so it slots into the existing /v1/ai/* namespace alongside /v1/ai/chat, /v1/ai/stream, etc. Pick whichever path fits your routing.

Upload an image and get back a short-lived public URL you can pass to /v1/ai/vision as image_url.

Vision providers fetch image URLs from their own infrastructure (so the URL must be publicly reachable). This endpoint hands you exactly that — a URL on the Endpointr public uploads volume, valid for 30+ minutes.

Request:
- image_base64 — raw base64 (no data: URI prefix). The 1x1 PNG below is real and uploads cleanly; substitute your own bytes.
- format? — png | jpeg | webp | gif. Optional — magic bytes are sniffed and trusted over a caller hint.

Limits. Max raw size 25 MB. Allowed formats above.

Response. {url, mime, format, bytes, expires_in: 1800, expires_at: <iso8601>}. The 32-hex token in the URL has 128 bits of entropy; URL is the secret (no auth on download — necessary because vision providers can't carry your JWT).

TTL. 30 minutes minimum. A cron job in the backup container deletes files older than 30 minutes every 5 minutes — effective lifetime is 30-35 minutes. After that the URL 404s.

Required body: image_base64.

Minimal body: {"image_base64":"iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkAAIAAAoAAv/lxKUAAAAASUVORK5CYII="}

List the 50 most recent video predictions for the authenticated customer (newest first). Same row shape as GET /v1/ai/video/{id}. Read-only — does not trigger any upstream poll.

_Requires stored credentials: atlascloud (PUT /v1/credentials/atlascloud)._

Poll a video generation by our internal id (returned from POST as id) — never AtlasCloud's prediction_id. Cross-customer access returns 404.

Behavior. If status is terminal (completed/failed/timeout), returns the cached row instantly without hitting upstream. If still processing, fires one upstream poll, updates the row, and returns. On status transition we fire VideoHandler.complete (success) or VideoHandler.failed (failure/timeout).

Response.

{"id":123,"provider":"atlascloud","model":"bytedance/seedance-2.0/text-to-video","prediction_id":"pred_abc","status":"completed","prompt":"...","outputs":["https://cdn.atlascloud.ai/.../video.mp4"],"error":null,"created_at":"...","completed_at":"..."}

Output URLs are AtlasCloud-hosted. Treat them as time-limited; download and re-host if you need durable storage.

_Requires stored credentials: atlascloud (PUT /v1/credentials/atlascloud)._

Async video generation via AtlasCloud (fronts Google VEO 3.1 Lite/Fast/Pro and ByteDance Seedance 2.0).

Two-step flow. POST returns immediately with {id, prediction_id, status: "processing"}. Poll GET /v1/ai/video/{id} until status is completed, failed, or timeout. Completed predictions are cached server-side — subsequent GETs return instantly without hitting AtlasCloud.

Required body fields: model, prompt. The model string is forwarded verbatim to AtlasCloud.

URL-bearing fields (image, last_image, images[], reference_images[], reference_videos[], reference_audios[]) must be public https URLs or data: URIs. The server runs an SSRF check before forwarding — internal/private IPs are rejected as 400.

Param whitelist (union across families; AtlasCloud rejects per-model mismatches): duration, resolution, ratio/aspect_ratio, image, last_image, images, reference_images, reference_videos, reference_audios, generate_audio, web_search, watermark, return_last_frame, seed, negative_prompt. Anything outside this list is silently dropped.

Webhook events: VideoHandler.complete and VideoHandler.failed fire on the customer's poll that detects the transition (subscribe via POST /v1/webhooks). The standard .create/.get/.getAll events fire as usual.

Response. {id, provider:"atlascloud", model, prediction_id, status:"processing", created_at}. Save id and poll the GET endpoint.

---

Mode bodies:

*Seedance 2.0 — text-to-video (canonical):*

{"model":"bytedance/seedance-2.0/text-to-video","prompt":"A red fox running through snow at sunrise, cinematic.","ratio":"16:9","duration":5,"resolution":"1080p","generate_audio":true}

*Seedance 2.0 — image-to-video:*

{"model":"bytedance/seedance-2.0/image-to-video","prompt":"The subject turns slowly toward the camera.","image":"https://example.com/frame.jpg","ratio":"16:9","duration":5}

*Seedance 2.0 — reference-to-video (style + motion + audio):*

{"model":"bytedance/seedance-2.0/reference-to-video","prompt":"Match the references.","reference_images":["https://example.com/style.jpg"],"reference_videos":["https://example.com/motion.mp4"],"reference_audios":["https://example.com/music.mp3"]}

*Seedance 2.0 Fast variant* — same shapes with bytedance/seedance-2.0-fast/... (e.g. bytedance/seedance-2.0-fast/text-to-video).

*VEO 3.1 — text-to-video:*

{"model":"google/veo3.1/text-to-video","prompt":"Drone shot over alpine lake at golden hour.","aspect_ratio":"16:9","duration":8,"resolution":"1080p","seed":42,"negative_prompt":"blurry, low quality"}

*VEO 3.1 — image-to-video* (Lite / Fast / Pro):

{"model":"google/veo3.1-fast/image-to-video","prompt":"The subject slowly turns toward the camera.","image":"https://example.com/start.jpg","aspect_ratio":"16:9","duration":8}

*VEO 3.1 — start-end-frame-to-video* (Lite / Fast / Pro; both frames required):

{"model":"google/veo3.1/start-end-frame-to-video","prompt":"Smooth dolly between the two frames.","image":"https://example.com/start.jpg","last_image":"https://example.com/end.jpg","aspect_ratio":"16:9","duration":8}

*VEO 3.1 Pro — reference-to-video* (Pro tier only):

{"model":"google/veo3.1/reference-to-video","prompt":"Render the subject in the painterly style of the reference.","images":["https://example.com/subject.jpg","https://example.com/style.jpg"],"resolution":"1080p","generate_audio":true}

Errors. Create-time AtlasCloud 4xx/5xx surface as the same status with {error, upstream:{...}}. A *prediction* that fails after creation is not a create-time error — it surfaces on poll as status: "failed" with error text.

Minimal body: {"model":"bytedance/seedance-2.0/text-to-video","prompt":"A red fox running through snow at sunrise, cinematic.","ratio":"16:9","duration":5,"resolution":"1080p"}

_Requires stored credentials: atlascloud (PUT /v1/credentials/atlascloud)._

Image + text in, text out. Same provider/credential semantics as /v1/ai/chat.

Supported providers: claude-cli, openai, anthropic, openrouter. openai-cli does not support vision (returns 501).

image_url is either:
- a public https URL (jpeg / png / gif / webp), or
- a data:image/png;base64,... URI for inline images, or
- the URL handed back by POST /v1/ai/upload (recommended for client-side uploads — see that endpoint).

Other example bodies.

Explicit Anthropic API:

{"provider":"anthropic","model":"claude-sonnet-4-6","prompt":"Describe what you see.","image_url":"https://upload.wikimedia.org/wikipedia/commons/thumb/4/4d/Cat_November_2010-1a.jpg/640px-Cat_November_2010-1a.jpg","max_tokens":500}

Claude-CLI with body-supplied token:

{"provider":"claude-cli","model":"claude-sonnet-4-6","oauth_token":"{{claude_oauth_token}}","prompt":"What is in this image?","image_url":"https://upload.wikimedia.org/wikipedia/commons/thumb/4/4d/Cat_November_2010-1a.jpg/640px-Cat_November_2010-1a.jpg","max_tokens":500}

OpenAI with a data-URI image (handy for tiny images you don't want to host):

{"provider":"openai","model":"gpt-4o-mini","prompt":"What's in this image?","image_url":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkAAIAAAoAAv/lxKUAAAAASUVORK5CYII="}

Minimal body: {"prompt":"What is in this image?","image_url":"https://upload.wikimedia.org/wikipedia/commons/thumb/4/4d/Cat_November_2010-1a.jpg/640px-Cat_November_2010-1a.jpg","max_tokens":500}

List every event name that a handler can emit.

List webhooks registered under your account.

Register a webhook URL for an event.

Response includes a secret (returned once) — receivers verify HMAC-SHA256 against the JSON body via the X-Endpointr-Signature: sha256=… header.

Meta Marketing events fired by the inbound /v1/webhooks/inbound/meta-ads endpoint use names of the shape MetaAds.<object>.<field> — e.g. MetaAds.page.leadgen, MetaAds.ad_account.adsstatus. Subscribe to those exactly the same way as any other event name.

Delete one of your webhooks.

Meta's webhook subscription handshake. NOT JWT-protected — Meta hits this with hub.mode=subscribe&hub.verify_token=…&hub.challenge=… and expects the challenge echoed back as plain text.

The verify token is set app-wide via the META_WEBHOOK_VERIFY_TOKEN env var (must match what you pass to POST /v1/marketing/webhook-subscriptions). 403 on mismatch.

Meta's webhook delivery endpoint. NOT JWT-protected — authenticity is verified via HMAC-SHA256 of the raw body against the per-customer app_secret (stored at slug meta-ads).

Flow per delivery: persist raw event → resolve customer by matching entry[].id against meta_ad_webhook_subs.object_id → verify HMAC → fan out via the standard WebhookManager (event name MetaAds.<object>.<field>) → enqueue a leadgen_fetch worker job for any leadgen field changes (so the full lead body lands in meta_ad_leads).

Always responds 200 — even on signature mismatch or unknown object_id — to prevent Meta retry storms. Forensics: unmatched/unverified deliveries are kept in meta_ad_webhook_events with customer_id=NULL for audit.

Implemented. Resolve a domain to a company profile built from two independent legs:

1. Crawler leg — /v1/crawlers/* waterfall (social-profiles → phone → email → cvr → cms) against the website. Zero API tokens unless SCRAPEDO_API_KEY is set, in which case fetches go through scrape.do (spends credits — needed to clear Cloudflare managed-challenge pages).
2. Enrichment leg — the customer's admin-ordered enrichment_priority list is walked with a company-shaped query; the first provider that returns a hit wins. The raw response lands at company.enrichment.data._raw for inspection while we map fields.

Renamed from /v1/profylr/domain. Endpointr now treats contact (person) and company as two top-level entities — same async machinery, separate routes.

Selectors.
- ?domain=example.com (or ?url=https://example.com/anything — the host is extracted). One is required; a bad/missing value → 400.
- ?country=dk|no|se|… (optional, ISO-2). A .com may actually be a Danish/Swedish/Norwegian company; passing country does two things: it tells the CVR crawler which org-number format to look for (DK 8-digit CVR / NO 9-digit / SE 10-digit, all prefix-guarded against PII false positives) and it sets scrape.do's geoCode so the page is fetched from that country's IP (helps when content is geo-routed). Different countries are *different* enqueued jobs (separate idempotency).
- ?refresh=true (also ?bypass_cache=true / ?force=true) bypasses the TTL freshness check and enqueues a fresh crawl regardless. A cached company doc, if present, is still returned in this response (marked freshness: "stale"); the refreshed copy will land on the next poll.

Async (profylr_jobs). Both legs run in the enrichment worker, so the response is immediate. freshness is reconciled against the job queue's real state — pending/stale are only ever reported while a job is genuinely queued or running:
- pending — no data yet; a company_crawl job is queued/running. Poll again, or use sync=1.
- stale — cached doc returned now; a refresh is queued/running.
- fresh — cached within TTL (PROFYLR_DOMAIN_TTL_DAYS, default 30); nothing enqueued.
- not_found — terminal. The pipeline completed (or no provider is runnable for this query) and no data was found. Polling will not change the answer; refresh=1 re-runs the work.
- failed — terminal. The background job exhausted its retries. Plain polls do NOT revive it (that would retry forever); refresh=1 revives explicitly.

Sync mode. ?sync=1 (alias ?wait=1) holds the request open until the enqueued job finishes — ?timeout= seconds, 1-25, default 20 — and returns the final profile in one round-trip. The response carries sync: {requested, waited_ms, outcome: completed|failed|timeout|no_wait}. Requires the enrichment worker to be running; without it the wait times out and the regular async answer is returned.

data: {domain, country, refresh, freshness, found, job_status, enqueued, es_status, company, checked_at, note}. found says whether the doc carries actual findings (not just bookkeeping); job_status mirrors the queue row (pending|claimed|completed|failed) or null. company is the profylr_companies doc (or null until the first crawl lands) with the crawler output under web_crawl and the provider waterfall under enrichment.

403 if the domain is in profylr_optouts (when PROFYLR_ENFORCE_OPTOUT=true).

Required query: domain.

Minimal query: {"domain":"example.com"}

Specified, not yet implemented — present so the collection documents the Phase 1 contract (docs/api.md).

Data Subject Request. operation: export (full machine-readable bundle of every field held, with provenance) or erase (tombstone + removal across all ES indices and the job queue). identifier is an email, LinkedIn slug/URL, GitHub username, or person_id.

202 accepted — processed asynchronously and audited · 401 missing/invalid/revoked JWT · 404 no such data subject. Runbook: docs/compliance/dsr-handling-runbook.md.

Specified, not yet implemented — present so the collection documents the Phase 1 contract (docs/api.md).

Register an opt-out. scope ∈ email | domain | person; value is the address / domain / person_id. Omit channels to opt out of every channel, or pass an array of channel keys to scope it. reason is free text for the audit trail.

201 recorded · 401 missing/invalid/revoked JWT. Enforced by the lookup API and every drafter; writes a profylr_audit row.

Implemented (email selector). Resolve a person by email and attach the token-free domain crawl as the basis.

Selectors.
- ?email=jane@acme.com (required). Validated; the canonical person doc is keyed by email (a ULID person_id is minted; deterministic dedupe by email). ?linkedin=, ?github=, ?name=&company= are in docs/api.md but return a clear 400 in this phase (probabilistic identity *merge* is deferred).
- ?country=dk|no|se|… (optional, ISO-2). Forwarded to the domain crawl (CVR pattern + scrape.do geoCode).
- ?refresh=true bypasses the TTL freshness check and enqueues a fresh crawl.

Email → domain. If the email domain is a generic free-mail provider (gmail, outlook, yahoo, proton, …; extend via PROFYLR_GENERIC_EMAIL_DOMAINS), the waterfall is skipped (domain_enrichment: "skipped_generic"). Otherwise the employer domain is crawled asynchronously and linked.

Async (profylr_jobs). Same freshness model as Company lookup, reconciled against the job queue's real state: pending/stale only while a job is genuinely queued or running; not_found (pipeline completed, nothing found) and failed (job exhausted retries) are terminal — polling will not change them, refresh=1 re-runs. Provider slugs the worker cannot actually attempt (unwired / no stored credentials / unsupported query shape) never count toward freshness, so the endpoint cannot ask you to poll for work that will never run.

Sync mode. ?sync=1 (alias ?wait=1) holds the request open until the job finishes — ?timeout= seconds, 1-25, default 20 — and returns the final profile in one round-trip; the response carries sync: {requested, waited_ms, outcome: completed|failed|timeout|no_wait}. Requires the enrichment worker to be running.

data: {email, domain, domain_generic, domain_enrichment, email_enrichment, country, refresh, freshness, found, job_status, enqueued, es_status, person, checked_at, note}. personal_context is never returned (hard rule).

403 if the email or its domain is opted out.

Required query: email.

Minimal query: {"email":"jane@example.com"}

Implemented. Bridge smoke test for the Profylr module: proves composer PSR-4 autoload, the reflection-router route, and the shared endpointr JWT middleware all line up. Returns the standard envelope with data: {profylr:"ok", version, php, customer_id, generated_at}.

Auth. Standard endpointr JWT — Authorization: Bearer {{token}} (issue via POST /v1/token with your api_key). No/expired/revoked JWT → 401. This is the *same* JWT as the rest of /v1/*; Profylr is not on profylr.endpointr.com (that vhost is the operator console only).

List settlements.

_Requires stored credentials: clearhaus (PUT /v1/credentials/clearhaus)._

Fetch settlement by id.

_Requires stored credentials: clearhaus (PUT /v1/credentials/clearhaus)._

List the configured PayPal account labels (stored as paypal:<label>). Pass one as account on any PayPal tool. No upstream call.

_Requires stored credentials: paypal (PUT /v1/credentials/paypal)._

Current available balance per currency — how much money is on the account. Optional query: currency_code, as_of_time (RFC3339, historical). Needs the app's Transaction Search feature; can lag live by ~3h.

_Requires stored credentials: paypal (PUT /v1/credentials/paypal)._

Get one billing plan by its id (P-…) — name, description, status, billing cycles, pricing.

_Requires stored credentials: paypal (PUT /v1/credentials/paypal)._

List billing plans — the NAMED recurring products. This is how you search subscriptions by name/description: pass name/description (filtered client-side within the fetched page; widen with page_size/page). Passthrough: product_id, page, page_size, total_required. Then read a subscriber's subscription via the subscriptions get.

Minimal query: {"name":"Pro","page_size":20}

_Requires stored credentials: paypal (PUT /v1/credentials/paypal)._

Get one invoice by its id (e.g. INV2-XXXX-XXXX-XXXX-XXXX).

_Requires stored credentials: paypal (PUT /v1/credentials/paypal)._

List invoices, or search when you pass filters. Filters (search): status (PAID|MARKED_AS_PAID|PARTIALLY_PAID|SENT|UNPAID|PAYMENT_PENDING|SCHEDULED|CANCELLED|REFUNDED), invoice_date_range/due_date_range ({start,end}), recipient_email, total_amount_range, invoice_number. Pagination: page, page_size, total_required. Overdue = outstanding past its due date (filter due_date_range, or use Overview). account selects the PayPal account.

Minimal query: {"status":"UNPAID","page_size":20,"total_required":"true"}

_Requires stored credentials: paypal (PUT /v1/credentials/paypal)._

One-call money snapshot: current balances, invoices bucketed paid / outstanding / overdue, and gross income over the last 30 days, grouped per currency. Start here. Balance/income need the app's Transaction Search feature; each source degrades independently into warnings. account selects which PayPal account (multi-account).

_Requires stored credentials: paypal (PUT /v1/credentials/paypal)._

Get one subscription by its id (I-…): status, plan_id, subscriber, billing_info (next billing time, last payment, outstanding balance). PayPal has no list/search for subscriptions — find the plan by name via the plans tool, then read a subscriber's sub by its I-… id.

_Requires stored credentials: paypal (PUT /v1/credentials/paypal)._

Transaction Search — the true overall income source (all payments received). Required: start_date + end_date (RFC3339), max 31 days apart; page by month for longer ranges. Optional: transaction_status (S|P|D|V), fields (default all), page, page_size (max 500). Needs the app's Transaction Search feature; data lags ~3h.

Minimal query: {"start_date":"2026-06-01T00:00:00Z","end_date":"2026-06-30T23:59:59Z","fields":"all"}

_Requires stored credentials: paypal (PUT /v1/credentials/paypal)._

Get one of accountGroups by {id}.

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

List accountGroups. Chart-of-accounts groups (each account belongs to a group, each group to a nature). Common params: page, pageSize (max 1000), sortProperty, sortDirection, include (sideload, e.g. accountGroups.contact:embed), q.

Minimal query: {"pageSize":100}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Create in accountGroups. Send the record fields directly (the relay wraps them in Billy's accountGroup root key and adds organizationId). Required: name, natureId.

Minimal body: {"name":"Software","natureId":"<nature-id>"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Update one of accountGroups by {id} (partial: only the fields sent change).

Minimal body: {"name":"Software"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Delete one of accountGroups by {id} (idempotent; Billy answers 200 even if already gone).

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Get one of accountNatures by {id}.

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

List accountNatures. The natures behind account groups (reportType revenue/expense/asset/liability/equity, normalBalance debit/credit). Common params: page, pageSize (max 1000), sortProperty, sortDirection, include (sideload, e.g. accountNatures.contact:embed), q.

Minimal query: {"pageSize":100}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Create in accountNatures. Send the record fields directly (the relay wraps them in Billy's accountNature root key and adds organizationId). Required: name.

Minimal body: {"name":"Expenses","reportType":"expense","normalBalance":"debit"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Update one of accountNatures by {id} (partial: only the fields sent change).

Minimal body: {"name":"Expenses"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Get one of accounts by {id}.

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

List accounts. The chart of accounts. isBankAccount=true finds the bank accounts bank lines need. Common params: page, pageSize (max 1000), sortProperty, sortDirection, include (sideload, e.g. accounts.contact:embed), q.

Minimal query: {"pageSize":100}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Create in accounts. Send the record fields directly (the relay wraps them in Billy's account root key and adds organizationId). Required: name, groupId.

Minimal body: {"name":"Hosting","groupId":"<group-id>","accountNo":7320}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Update one of accounts by {id} (partial: only the fields sent change).

Minimal body: {"name":"Hosting"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Delete one of accounts by {id} (idempotent; Billy answers 200 even if already gone).

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Get one of attachments by {id}.

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

List attachments. Files linked to a record (ownerReference like invoice:<id>). Filters: unhandled, handled, ownerReference, type, supplier, amount, documentDatePeriod, isDuplicate, eInvoiceFilter, q. Common params: page, pageSize (max 1000), sortProperty, sortDirection, include (sideload, e.g. attachments.contact:embed), q.

Minimal query: {"pageSize":100}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Create in attachments. Send the record fields directly (the relay wraps them in Billy's attachment root key and adds organizationId). Required: ownerReference, fileId.

Minimal body: {"ownerReference":"bill:<bill-id>","fileId":"<file-id>"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Update one of attachments by {id} (partial: only the fields sent change).

Minimal body: {"ownerReference":"bill:<bill-id>"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Delete one of attachments by {id} (idempotent; Billy answers 200 even if already gone).

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Get one of balanceModifiers by {id}.

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

List balanceModifiers. Links between a modifier (payment) and a subject (invoice/bill) that change a balance. Common params: page, pageSize (max 1000), sortProperty, sortDirection, include (sideload, e.g. balanceModifiers.contact:embed), q.

Minimal query: {"pageSize":100}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Create in balanceModifiers. Send the record fields directly (the relay wraps them in Billy's balanceModifier root key and adds organizationId). Required: modifierReference, subjectReference.

Minimal body: {"modifierReference":"bankPayment:<id>","subjectReference":"invoice:<id>"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Update one of balanceModifiers by {id} (partial: only the fields sent change).

Minimal body: {"modifierReference":"bankPayment:<id>"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Get one of bankLineMatches by {id}.

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

List bankLineMatches. A reconciliation match on a bank account (bank lines ↔ postings). Common params: page, pageSize (max 1000), sortProperty, sortDirection, include (sideload, e.g. bankLineMatches.contact:embed), q.

Minimal query: {"pageSize":100}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Create in bankLineMatches. Send the record fields directly (the relay wraps them in Billy's bankLineMatch root key and adds organizationId). Required: accountId.

Minimal body: {"accountId":"<bank-account-id>"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Update one of bankLineMatches by {id} (partial: only the fields sent change).

Minimal body: {"accountId":"<bank-account-id>"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Delete one of bankLineMatches by {id} (idempotent; Billy answers 200 even if already gone).

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Get one of bankLineSubjectAssociations by {id}.

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

List bankLineSubjectAssociations. Which subject (invoice, bill, posting) a bank line match settles. Common params: page, pageSize (max 1000), sortProperty, sortDirection, include (sideload, e.g. bankLineSubjectAssociations.contact:embed), q.

Minimal query: {"pageSize":100}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Create in bankLineSubjectAssociations. Send the record fields directly (the relay wraps them in Billy's bankLineSubjectAssociation root key and adds organizationId). Required: matchId, subjectReference.

Minimal body: {"matchId":"<match-id>","subjectReference":"invoice:<id>"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Update one of bankLineSubjectAssociations by {id} (partial: only the fields sent change).

Minimal body: {"matchId":"<match-id>"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Delete one of bankLineSubjectAssociations by {id} (idempotent; Billy answers 200 even if already gone).

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Get one of bankLines by {id}.

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

List bankLines. Imported bank statement lines. accountId is REQUIRED on list (find bank accounts with accounts isBankAccount=true); filters isReconciled, status (pending|booked), side, externalId, receiptState, minAmount, maxAmount, minEntryDate, maxEntryDate, entryDatePeriod, q. Common params: page, pageSize (max 1000), sortProperty, sortDirection, include (sideload, e.g. bankLines.contact:embed), q.

Required query: accountId.

Minimal query: {"pageSize":100}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Create in bankLines. Send the record fields directly (the relay wraps them in Billy's bankLine root key and adds organizationId). Required: matchId, accountId, entryDate, description, amount, side.

Minimal body: {"accountId":"<bank-account-id>","entryDate":"2026-09-01","description":"Stripe payout","amount":1200,"side":"debit"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Update one of bankLines by {id} (partial: only the fields sent change).

Minimal body: {"accountId":"<bank-account-id>"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Delete one of bankLines by {id} (idempotent; Billy answers 200 even if already gone).

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Get one of bankPayments by {id}.

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

List bankPayments. Register a payment against invoices or bills: cashSide debit = money in (invoices), credit = money out (bills); associations[].subjectReference = invoice:<id> / bill:<id>, all in the same currency. Common params: page, pageSize (max 1000), sortProperty, sortDirection, include (sideload, e.g. bankPayments.contact:embed), q.

Minimal query: {"pageSize":100}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Create in bankPayments. Send the record fields directly (the relay wraps them in Billy's bankPayment root key and adds organizationId). Required: entryDate, cashAmount, cashSide, cashAccountId, associations.

Minimal body: {"entryDate":"2026-09-15","cashAmount":1200,"cashSide":"debit","cashAccountId":"<bank-account-id>","associations":[{"subjectReference":"invoice:<invoice-id>"}]}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Update one of bankPayments by {id} (partial: only the fields sent change).

Minimal body: {"entryDate":"2026-09-15"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Delete one of bankPayments by {id} (idempotent; Billy answers 200 even if already gone).

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Get one of billLines by {id}.

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

List billLines. Lines of a supplier bill. Common params: page, pageSize (max 1000), sortProperty, sortDirection, include (sideload, e.g. billLines.contact:embed), q.

Minimal query: {"pageSize":100}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Create in billLines. Send the record fields directly (the relay wraps them in Billy's billLine root key and adds organizationId). Required: billId, accountId, taxRateId, description, amount.

Minimal body: {"billId":"<bill-id>","accountId":"<account-id>","taxRateId":"<tax-rate-id>","description":"Hosting september","amount":800}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Update one of billLines by {id} (partial: only the fields sent change).

Minimal body: {"billId":"<bill-id>"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Delete one of billLines by {id} (idempotent; Billy answers 200 even if already gone).

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Get one bill by {id}.

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

List supplier bills (documented filters allow-listed: contactId, creditedBillId, minEntryDate, maxEntryDate, minDueDate, maxDueDate, isPaid, hasAttachments, state draft|approved|voided, currencyId, suppliersInvoiceNo, isBare, amount, q, sortProperty, sortDirection, include, page, pageSize).

Minimal query: {"state":"approved","pageSize":100}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Create a DRAFT bill (record fields; lines may be embedded, each {accountId, taxRateId, description, amount}). Via action: approve (id) books it; credit_note (id of the bill to credit) creates a credit note. Required: contactId, entryDate, paymentDate.

Minimal body: {"contactId":"<supplier-contact-id>","entryDate":"2026-09-01","paymentDate":"2026-09-30","suppliersInvoiceNo":"INV-123","lines":[{"accountId":"<account-id>","taxRateId":"<tax-rate-id>","description":"Hosting","amount":800}]}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Update a draft bill by {id} (partial).

Minimal body: {"paymentDate":"2026-10-05"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Delete a draft bill by {id} (idempotent).

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Get one of cities by {id}.

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

List cities. Reference data: cities. Common params: page, pageSize (max 1000), sortProperty, sortDirection, include (sideload, e.g. cities.contact:embed), q.

Minimal query: {"pageSize":100}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Create in cities. Send the record fields directly (the relay wraps them in Billy's city root key and adds organizationId).

_Requires stored credentials: billy (PUT /v1/credentials/billy)._

Update one of cities by {id} (partial: only the fields sent change).

Minimal body: {"name":"Renamed"}

_Requires stored credentials: billy (PUT /v1/credentials/billy)._