All integrations

Endorsal

MARKETING · MARKETING

Testimonials, the contacts they were requested from, and the widgets that publish them.

Connecting Endorsal in practice

Endorsal answers 429 for two unrelated conditions: fifty calls a second against one set of credentials, and a hard monthly call allowance set by the plan. The first clears in a second and the second does not clear until the month does, and nothing in the response distinguishes them, so retry logic that treats 429 as backpressure will spin for weeks against an exhausted plan.

Scopes that draw scrutiny

  • Authorization: Bearer <API_KEY> Required on everything except GET. Keys are generated per property from the dashboard API page, so a customer with several properties has several credentials.
  • key query parameter GET requests may pass the key as a query parameter instead of the header, which Endorsal offers for testing and which puts the credential in logs.

Rate limits

  • Fifty API calls per second per set of API credentials.
  • A hard monthly call total set by the plan; exceeding it also returns 429.
  • Endorsal explicitly recommends against sharing one credential set between multiple consumer apps because they share the per-second budget.

Worth knowing

  • Keys are minted per property rather than per account, and can be invalidated from the dashboard at any time, so a working integration can be revoked by anyone with UI access without touching the account.
  • Because both the per-second limit and the monthly allowance surface as 429, a client has to track its own call count to know which one it hit.
  • The base URL is api.endorsal.io/v1 while the documentation lives on a separate Stoplight host, so the reference and the API are not on the same domain.

Checked against Endorsal Public API (2026-09-29), Endorsal developer center (2026-09-29)

Acts as the person, not as itself

Each user connects their own account. Every call carries both identities — the agent and the person it is acting for — so the agent can never reach past what that individual can already do.

Credentials never touch the agent

Tokens live in the vault and attach server-side at call time. The agent holds a session, not a secret, and revoking access does not mean rotating a key.

Every call on the record

Who asked, which agent acted, which action ran, and the verdict that let it through — one audit trail across every integration, not one per vendor.

What an agent can do

Each action is granted on its own. An agent allowed to read is not thereby allowed to write, and the scope beside each row is what the acting user must have connected for it to run at all.

endorsal_get_v1_contactsREAD

List the contacts on this connection's Endorsal property -- the customers a testimonial request can be sent to -- each with their name, email and the tags applied to them via GET /v1/contacts

api
endorsal_get_v1_contacts_by_idREAD

Fetch one contact by id, with their profile fields and tags. An id that is not on this property answers 200 with an empty `data` object rather than a 404. The id must be a 24-character hex ObjectId via GET /v1/contacts/{id}

api
endorsal_get_v1_contacts_by_id_testimonialsREAD

List every testimonial this one contact has left. This is the way to check whether a customer has already responded before sending another request; the contact id comes from the List contacts tool via GET /v1/contacts/{id}/testimonials

api
endorsal_get_v1_propertiesREAD

List the Endorsal properties this token reaches. It returns exactly ONE: an Endorsal API token is minted against a single property and carries its id in the token itself, so a tenant with several properties needs a separate connection and a separate token for each. Use this tool to confirm which property a connection is actually pointed at via GET /v1/properties

api
endorsal_get_v1_properties_by_idREAD

Fetch one property's settings -- its name, domain, rating configuration and branding. Only this connection's own property can be read: any other id answers 200 with `{"success": false, "error": "Invalid credentials"}`, which is Endorsal saying the property is not the one this token was issued for rather than that the token is bad via GET /v1/properties/{id}

api
endorsal_get_v1_tagsREAD

List the tags defined on this property. Tags are how contacts are segmented for testimonial campaigns, so this is the vocabulary the contact records draw from via GET /v1/tags

api
endorsal_get_v1_testimonialsREAD

List the testimonials collected for this connection's Endorsal property, each with its author, rating, body text and current status. An Endorsal API token is issued against ONE property, so this returns that property's testimonials and not the whole account's via GET /v1/testimonials

api
endorsal_get_v1_testimonials_by_idREAD

Fetch one testimonial by its id. Endorsal answers 200 with `{"success": false, "error": "No testimonial found matching that ID"}` rather than a 404 when the id is unknown, so read `success` and not the status code. The id must be a 24-character hex ObjectId; any other shape answers 500 from Endorsal's own id parser via GET /v1/testimonials/{id}

api
endorsal_get_v1_widgetsREAD

List the display widgets configured on this property -- the carousels, walls and badges that publish collected testimonials on a website -- each with its id, type and configuration via GET /v1/widgets

api
endorsal_get_v1_widgets_by_idREAD

Fetch one widget's full configuration by id. An id that is not on this property answers 200 with an empty `data` object rather than a 404 via GET /v1/widgets/{id}

api

Put Endorsal behind one governed endpoint.

Same permissions, same audit trail, whatever else you connect next.