Dsc Endpoint Help

Original name

Original description

Look up a spec field on, or diff a failing request against, one named endpoint in a Salesforce API reference published on developer.salesforce.com ("DSC"). Invoke whenever the user's ask is about what one specific endpoint's spec says or why one specific call doesn't match it – OAuth scopes, query params, request body, response schema, auth scheme, HTTP method/path, or a cURL/HTTP request paired with an error body (`invalid_client`, `insufficient_scope`, `400 missing_parameter`, `401 AuthenticationFailedException`, `415` content-type, etc.). Covers spec-field lookups ("what scopes does shopper-products getProducts need?", "which query params does searchOrders take?", "what auth scheme guards createOrder?"), code-generation asks against a named endpoint ("write me a node script that calls getProduct" – quote the spec; don't write the code), how-to asks that are really spec-field questions ("how do I paginate searchOrders", "what limit does X accept"), and failing-request diagnosis ("why is this 403ing", "diff this against the spec", "what scope is missing"). This is the unified successor to `dsc-endpoint-lookup` and `dsc-triage`; prefer it whenever either of those would have fired – the runtime branches internally on whether a failing request is attached. Every claim cited to a public developer.salesforce.com URL. Works against any DSC reference `dsc-scrape` can deliver. Hands off honestly for errors the spec can't explain (5xx, 404 path-or-resource-missing, 409 conflicts). Decline when no endpoint field is in scope at all: concept or comparison questions without a named endpoint ("what's the difference between OCAPI and SCAPI", "what is SLAS"), parsing a user-supplied local file rather than a DSC reference ("parse my ~/work/foo.json"), scraping whole references wholesale (that's `dsc-scrape`), multi-call ordering / scenario-building (that's `dsc-scenario`), and guides / concept pages / atlas-format books / release notes. Also decline questions about what a separate runtime consumer of the response requires – Customer Service Center field dependencies, SFRA hook semantics, "which response fields can my custom hook null out without breaking X" – even when an endpoint is named; the spec describes the endpoint's own input/output, not what other runtimes downstream of the response do with it, so any spec-framed answer would be fabrication.