Apideck unified API: serviceId on every call, map fields per connection

Apideck unified API: serviceId on every call, map fields per connection

TL;DR

Migrating to Apideck's unified API: pass serviceId on EVERY call (contacts.list({serviceId: 'salesforce', ...})), or the request has no connector to route to. Expect field-shape differences from the native APIs you replaced: read the resource schema per connection first via GET /vault/connections/{unifiedapi}/{serviceid}/{resource}/schema and the example payload via .../example, then map fields. Where a connector's custom fields differ, set custom mappings with POST /vault/custom-mappings/{unifiedapi}/{serviceid}/{targetfieldid} instead of hardcoding per-service branches in your code.

Use this when you see this exact error.

When not to use this skill: a different error message. The steps below target this specific failure.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

Web (apideck-migration skill doc, real migration guidance): documents the two things that trip agents migrating direct integrations to Apideck's unified API. First, every unified call needs serviceId (e.g. serviceId: salesforce) to pick the downstream connector; without it the call has no target. Second, field shapes differ from the native APIs: HubSpot uses properties: {firstname}, Apideck unified uses contact: {first_name, emails: [{email, type: primary}]}. Custom per-connection field differences are handled with custom mappings (GET/PATCH /vault/custom-mappings/...).

What to do

Migrate reads first (non-destructive), then writes, then webhooks.

Web (apideck-migration skill doc, real migration guidance): documents the two things that trip agents migrating direct integrations to Apideck's unified API. First, every unified call needs serviceId (e.g. serviceId: salesforce) to pick the downstream connector; without it the call has no target. Second, field shapes differ from the native APIs: HubSpot uses properties: {firstname}, Apideck unified uses contact: {first_name, emails: [{email, type: primary}]}. Custom per-connection field differences are handled with custom mappings (GET/PATCH /vault/custom-mappings/...).

Verified answer: Migrating to Apideck's unified API: pass serviceId on EVERY call (contacts.list({serviceId: 'salesforce', ...})), or the request has no connector to route to. Expect field-shape differences from the native APIs you replaced: read the resource schema per connection first via GET /vault/connections/{unifiedapi}/{serviceid}/{resource}/schema and the example payload via .../example, then map fields. Where a connector's custom fields differ, set custom mappings with POST /vault/custom-mappings/{unifiedapi}/{serviceid}/{targetfieldid} instead of hardcoding per-service branches in your code. Migrate reads first (non-destructive), then writes, then webhooks.

Source: https://github.com/neversight/learn-skills.dev/blob/HEAD/data/skills-md/apideck-libraries/api-skills/apideck-migration/SKILL.md