Undocumented access gate

Payments / business operations platform·agent-generated · deepseek-v4.1-flash·checked 2026-10-28

DashX Payments

difficulty

3/5

A real OAuth 2.0 authorization server is live at api.dashx.com with six scopes, but there is no registration endpoint and no docs, so the gate is a manual client_id request plus an unknown review wait — and there is no OIDC and no payments scope.

First working connection

~1–3 hours after a client_id exists

Production / approved

client_id wait ~1–3 days + unknown review; assume 1–4 weeks

Composio managed OAuth

Bring your own app

Not in Composio's managed-OAuth list — you'll need your own OAuth app (or it isn't a Composio toolkit yet).

who does itagent 5you 3provider 0

evidencetested 32sourced 0inferred 12

◆ agent run0 pages read0/0 quotes verified verbatim25s$0.010deepseek-v4.1-flash

01Pick your path

Authorization-code OAuth (api.dashx.com)

when You can get a client_id and secret from the DashX team and your integration stays within the six published scopes.

→ Per-user delegated token for messaging/planner/views/analytics, if DashX will issue you a client_id.

OIDC / social login

when Never, based on current probes; only revisit if DashX publishes OIDC.

→ Dead end — /openid-configuration returns 404 on dashx.com and api.dashx.com. No id_token or userinfo.

Partner/business integration

when You need payment/transaction actions that the public scope list does not cover.

→ Presumably a contract plus custom credentials; timeline and terms unknown.

API key / server-to-server (unverified)

when Only if DashX support confirms a non-OAuth machine credential exists.

→ Not evidenced by any probe or source; do not plan around it without confirmation.

02Time & effort

Hands-on work

1.6 h – 4.3 h

Waiting on others

9 days – 5 weeks

You're actually working

<1% of elapsed time

Phases

start↑ first working connection, then production pathproduction

DEVRead the real authorization-server metadata5–15 minutestested[probe]
DEVObtain a client_id (no self-serve registration)wait 1–3 daystested[probe]Inferred duration; depends entirely on DashX support responsiveness. Metadata lists no registration_endpoint and an unregistered client_id gets a 400.
DEVImplement authorize → callback → token exchange1–3 hoursinferredStandard OAuth code flow; add PKCE and refresh-token storage. Error bodies are text/plain, so parse defensively.
DEVEnd-to-end test against a real DashX account30–60 minutesinferred
PRODJustify write scopes and get them enabledwait 1–5 daysinferredUnknown whether write scopes are granted on request or gated by review.
PRODProvider production reviewwait 1–4 weeksinferredPure estimate — no source documents a review process at all.

agent can do it you waiting on providerbar widths ∝ √time, so short tasks stay visible

03Steps

0/8 done

Get a working connection

Distinguish the false-positive discovery hostsagenttested[probe]
auth.dashx.com answers 200 with text/html on both well-known paths — that is a front-end fallback, not metadata. Only the API host serves JSON. Any discovery logic you write must validate content-type and JSON-parse before trusting a 200.
◆ prepared by agent · Content-type sanity check
```
curl -sS -D- -o /dev/null https://auth.dashx.com/.well-known/oauth-authorization-server | grep -i content-type
curl -sS https://api.dashx.com/.well-known/oauth-authorization-server | jq .
```

Pin endpoints and scopes into configagenttested[probe]

Cache the issuer https://api.dashx.com, the two endpoints, and the six scopes. Do not assume OIDC fields: /openid-configuration is 404 on both dashx.com and api.dashx.com.

◆ prepared by agent · dashx-oauth.json

{
  "issuer": "https://api.dashx.com",
  "authorization_endpoint": "https://api.dashx.com/oauth/authorize",
  "token_endpoint": "https://api.dashx.com/oauth/token",
  "scopes": ["messaging:read","messaging:write","planner:read","planner:write","views:read","views:write","analytics:read"],
  "pkce": "unverified"
}

Ask DashX for a client_id and the registration processyoutested[probe]

There is no published registration endpoint and no docs were fetchable, so a registered client is the hard prerequisite. An unknown client_id is rejected with 400 before any login UI, which confirms clients are pre-provisioned. Everything about timing here is unknown — ask explicitly.

◆ prepared by agent · Registration enquiry email

Subject: OAuth client registration for a DashX integration

Hi DashX team,

We're building an integration that acts on behalf of our users. Your authorization server at https://api.dashx.com publishes metadata with authorize/token endpoints and the scopes messaging:*, planner:*, views:*, analytics:read, but advertises no registration_endpoint, and an unregistered client_id is rejected at /oauth/authorize.

Could you confirm:
1. How third-party clients are registered (console, support request, or partner agreement)?
2. Whether PKCE (S256) and the authorization_code + refresh_token grants are supported.
3. Which redirect URI schemes/hosts you accept, and any review required before production.
4. Whether there is a payments/transactions scope or API for agents, and if not, how payment actions are meant to be performed.
5. Expected timeline from request to usable production credentials.

We need messaging:read and planner:read to start; write and analytics scopes only if the above is workable.

Thanks,
[Your name]

Build the authorization request with least privilegeagenttested[probe]

Start with read-only scopes only: messaging:read and planner:read. Generate and store state, and attach PKCE even though the metadata is silent on it. Never request write scopes you cannot justify in the consent screen.

◆ prepared by agent · Authorize URL builder (narrowest scopes)

const p = new URL('https://api.dashx.com/oauth/authorize');
p.searchParams.set('client_id', process.env.DASHX_CLIENT_ID);
p.searchParams.set('response_type', 'code');
p.searchParams.set('redirect_uri', 'https://yourapp.com/oauth/dashx/callback');
p.searchParams.set('scope', 'messaging:read planner:read');
p.searchParams.set('state', crypto.randomUUID());
// PKCE unverified - send it and be ready to fall back
p.searchParams.set('code_challenge', challenge);
p.searchParams.set('code_challenge_method', 'S256');
console.log(p.toString());

Handle the callback and token exchange defensivelyagenttested[probe]
Exchange at https://api.dashx.com/oauth/token, validate state, persist tokens server-side. Handle non-JSON error bodies: the authorize endpoint already returns text/plain, so wrap every response in a content-type check before .json().
Prove scope enforcement in a real accountyouinferred
You need a live DashX account to consent and to confirm which scopes actually gate which API calls — this is the only way to learn whether the published scopes map cleanly onto the endpoints you need.

Make it production-ready

Design around the two absences: no OIDC, no payments scopeyoutested[probe]
Do not design an id_token or userinfo flow: openid-configuration is 404 on both hosts. Get user identity from your own login. And note that no payments scope is published, so keep money movement on your backend instead of assuming the agent can do it.

Send a scope justification with the requestagentinferred

Write one line per scope, tie each to a user-visible feature, and explicitly name the scopes you are not requesting. Send it with the registration email so scope review does not become a second round trip.

◆ prepared by agent · Scope justification draft

Scope justification - DashX integration

messaging:read - list and read the user's message threads to summarise unanswered questions. Read-only; no message content is stored beyond the session.
planner:read - read the user's plans so the agent can report status on request.
(Not requested initially)
messaging:write - only if the user explicitly asks the agent to reply.
views:write / planner:write - only for agents that edit shared plans.
analytics:read - only if the agent reports metrics; aggregates business data.

04Requirements, scopes & nuances

You'll need

▸A pre-registered client_id (and presumably client secret) issued by DashX — dynamic client registration is not advertised. tested[probe]
▸A pre-registered, HTTPS redirect URI on a domain you control; a visible callback handler that exchanges the code at https://api.dashx.com/oauth/token. inferred
▸Secure refresh-token storage (server-side, encrypted) if refresh_token is granted — unverified from metadata. inferred
▸A tolerance for non-JSON responses: authorize errors return text/plain, so your HTTP layer must not assume JSON. tested[probe]
▸A written per-scope justification to send to DashX support, since no developer console or docs URL is published. inferred

Gotchas

!A 200 from a well-known endpoint proves nothing here: auth.dashx.com returns 200 + text/html on both /.well-known/openid-configuration and /.well-known/oauth-authorization-server. tested[probe]
!OIDC is not published on the API host — /openid-configuration is 404 — so expect no id_token, no userinfo endpoint, and no "Sign in with DashX" identity layer. tested[probe]
!The metadata names issuer https://api.dashx.com but advertises authorize/token on the same host — there is no separate login host, so the consent UI is at api.dashx.com/oauth/authorize. tested[probe]
!Six scopes only, all colon-separated nouns: messaging:read/write, planner:read/write, views:read/write, analytics:read. Request read scopes first; write scopes are the ones that will draw scrutiny. tested[probe]
!No code_challenge_methods_supported is published, so PKCE support is unverified — send PKCE anyway and test; if the server rejects it, fall back and note the risk. inferred
!No grant_types_supported, token_endpoint_auth_methods_supported, or revocation/registration endpoints are listed — assume authorization_code + refresh_token but verify each before shipping. inferred

Scope / permission	Tier	Note	Evidence
messaging:read	basic	List/read message threads. Ask for this first.	tested[probe]
messaging:write	sensitive	Agent sends messages on the user's behalf — user-visible side effects, so make it opt-in.	tested[probe]
planner:read	basic	Read plans/boards. Safe default for summarisation agents.	tested[probe]
planner:write	sensitive	Mutates the user's plans; justify each write action explicitly.	tested[probe]
views:read	basic	Read saved views; low risk but may expose business data.	tested[probe]
views:write	sensitive	Creates/modifies shared views — affects other users of the account.	tested[probe]
analytics:read	sensitive	Aggregate business metrics; request only when the agent actually reports numbers.	tested[probe]
payments (absent)	gated	No payments/transactions scope appears in scopes_supported. If the agent must move money, this AS may not support it — confirm before promising the feature.	tested[probe]

05If you get blocked

✕The planner marked OAuth "unclear" because auth.dashx.com returns 200 on both well-known paths — but the body is text/html, i.e. an app-shell fallback, not metadata.tested[probe]

→ Stop checking status codes; check Content-Type and JSON-parse the body. Only api.dashx.com returned real AS metadata. Add this check to your own smoke test.

✕No registration_endpoint is published, so you cannot self-register an OAuth client; an unregistered client_id is rejected (400) at the authorize endpoint.tested[probe]

→ Ask DashX for a client_id and secret via support/partner contact before writing any flow code; treat your own redirect URI as fixed once registered.

✕Authorize errors come back as text/plain HTML/login page, so a naive client that expects JSON error payloads will misparse failures.tested[probe]

→ Read the actual response body on errors (text/plain, not JSON) and log status + body. Do not assume JSON error objects.

✕The published scope list (messaging, planner, views, analytics) contains no payments or transactions scope, despite the "Payments" branding.inferred[probe]

→ Confirm in writing with DashX whether payment/transaction actions are exposed through this AS. If not, keep money movement on your own backend and use the agent only for reads (views:read, analytics:read).

06Evidence: what was tested, sourced, and still uncertain

$ probes: live GETs with a dummy client_id, no credentials

✓ Discovery document (/.well-known/openid-configuration) → 200

https://auth.dashx.com/.well-known/openid-configuration

non-JSON (text/html; charset=utf-8)

∴ Misleading: 200 but text/html. This is a front-end catch-all, not OIDC metadata. Do not build against it.

✓ Discovery document (/.well-known/oauth-authorization-server) → 200

https://auth.dashx.com/.well-known/oauth-authorization-server

non-JSON (text/html; charset=utf-8)

∴ Misleading: 200 but text/html. Same catch-all. This is likely the source of the "OAuth support is unclear" read.

✓ Discovery document (/.well-known/openid-configuration) → 404

https://dashx.com/.well-known/openid-configuration

not published

∴ Marketing site publishes no discovery document.

✓ Discovery document (/.well-known/oauth-authorization-server) → 404

https://dashx.com/.well-known/oauth-authorization-server

not published

∴ No authorization-server metadata on the marketing domain — expected.

✓ Discovery document (/.well-known/openid-configuration) → 404

https://api.dashx.com/.well-known/openid-configuration

not published

∴ OIDC is not offered on the API host: no id_token, no userinfo, no identity layer.

✓ Discovery document (/.well-known/oauth-authorization-server) → 200

https://api.dashx.com/.well-known/oauth-authorization-server

issuer=https://api.dashx.com; authorization_endpoint=https://api.dashx.com/oauth/authorize; token_endpoint=https://api.dashx.com/oauth/token; scopes_supported=messaging:read messaging:write planner:read planner:write views:read views:write analytics:read

∴ The one real signal: a live OAuth 2.0 authorization server with issuer https://api.dashx.com, authorize/token endpoints, and six scopes (messaging, planner, views, analytics).

✓ Authorize endpoint with a fake client_id → 400

https://api.dashx.com/oauth/authorize?client_id=probe_invalid_client&response_type=code&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback

text/plain; charset=utf-8 — HTML/login page

∴ Client validation runs before any login UI: an unknown client_id is rejected with 400 in text/plain. Registration with DashX is therefore required.

Sources read

[composio] Composio — Managed OAuth apps directory official
[probe] Live HTTP probes run by the agent (dummy client_id, no credentials) probe

Still uncertain

? No sources could be fetched — no DashX developer documentation, dashboard URL, or partner page is available, so nothing here is backed by provider statements.
? Whether DashX offers OAuth to third-party developers at all is unresolved; metadata exists, but it may be for first-party or partner apps only.
? No registration_endpoint is published, so the client-provisioning route (console vs. support ticket vs. contract) is unknown.
? PKCE support, refresh-token issuance, token lifetimes, revocation, and token_endpoint_auth_method are all unstated in the metadata.
? The published scopes contain nothing about payments or transactions, which conflicts with the product framing; treat payment actions as unsupported until DashX says otherwise.
? The 400 response on the fake client_id is described as a "login page" in text/plain — the exact consent/error UX could not be observed beyond that.
? All time estimates after metadata discovery are inferred; there is no evidence of a review process or its duration.
? auth.dashx.com returning 200 text/html may be an SPA fallback or an undocumented non-OAuth surface — unverified either way.
? Very few sources could be read; treat this guide as a starting point only.
? Generated automatically; no app was registered and no review was submitted.