Microsoft Dynamics 365 Sales vs Nutshell

Microsoft Dynamics 365 Sales

Dynamics 365 Sales data sits in Dataverse, reached through the OData v4 Web API or the Dataverse MCP server with 15 tools. Service protection limits are published and 429 responses carry Retry-After. Access needs an Entra app registration and an administrator, and the public service health page showed no history to our reader.

Nutshell

The REST reference is served as Markdown with an OpenAPI fragment per operation, and the hosted MCP server uses OAuth with PKCE and can only read. No rate limit numbers, error format or API changelog were found in the reviewed documentation, and API keys carry no scopes.

Microsoft Dynamics 365 Sales

1. Send OData-MaxVersion: 4.0, OData-Version: 4.0 and Accept: application/json, and name columns with $select on every read
2. Page with Prefer: odata.maxpagesize (up to 5,000) and follow @odata.nextLink. $skip is not supported
3. On 429, wait the seconds in Retry-After. The x-ms-ratelimit-* headers are for debugging, not pacing
4. Use PATCH on an alternate key to upsert, and add If-Match: * when an update must not create a record
5. For MCP, call describe for logical table and column names before read_query. Update any allow list that still names describe_table, list_tables or fetch

Nutshell

1. Authenticate REST calls with HTTP Basic, a Nutshell user's email as username and the API key as password, against https://app.nutshell.com/rest
2. Use IDs in the <number>-<type> form, such as 3-accounts, and send updates as JSON Patch with content-type: application/json-patch+json
3. Page lists with page[limit] and page[page], which is 0-based, and call /accounts/list/fields or the lead and contact equivalents for valid filter keys
4. Use the REST API for writes. The MCP server only reads, and OAuth tokens need the read scope
5. Filter webhook events yourself, because every webhook receives all events and subscriptions are created in Setup, not through the API