Salesforce REST Port

Purpose

This is the Harbor reference integration for the Salesforce REST API.

Use it when:

• building Salesforce actions in Harbor
• extending the Dock / Hub Salesforce entry
• teaching Codex or OpenClaw how to map CRM object discovery, bounded SOQL reads, and explicit record creation into Harbor Ports and Harbor Actions without turning Harbor into a generic Salesforce admin proxy

Harbor Port worksheet

Product

• Product: Salesforce REST API
• Publisher slug: salesforce
• Publisher name: Salesforce
• Category: CRM
• Tags: salesforce, crm, sobjects, records, soql

Safe Harbor Port metadata

• Kind: http_api
• Label: Salesforce REST API
• Description: Salesforce REST API connection managed locally through Harbor.
• Base URL: tenant-specific Salesforce instance root, for example https://your-domain.my.salesforce.com/
• Auth mode: header_token
• Auth header name: Authorization
• Auth token prefix: Bearer

Hidden local config

• authToken

Harbor stores the token locally only. Dock / Hub manifests must never contain it.

For Salesforce, operators should use the OAuth-returned instance URL as the Harbor base URL rather than a generic login or documentation host.

Harbor action design notes

Salesforce is a good Harbor fit when we keep the object surface explicit, SOQL readable, and record creation reviewable.

Good Harbor Salesforce starter actions:

• fixed GET reads for global object discovery
• one bounded GET query route with an explicit q parameter for SOQL
• one reviewable POST route for record creation on an explicit object API name
• requestBodyMode: "none" for reads
• requestBodyMode: "json" for create-record
• resultMode: "json_summary" for all starter actions

Avoid for now:

• arbitrary REST passthrough across the whole Salesforce surface
• metadata mutation, tooling API, or admin configuration flows
• bulk APIs, composite APIs, or delete/update operations before more policy coverage exists
• broad SOQL automation without explicit operator review of the query input

Starter Salesforce actions

Automatic read actions

• describe-sobjects -> GET /services/data/v66.0/sobjects
• query -> GET /services/data/v66.0/query?q=...

Approval-friendly write actions

• create-record -> POST /services/data/v66.0/sobjects/{objectApiName}/

Why these actions

These routes fit Harbor's current safe model because they:

• stay on stable REST resources under one explicit Salesforce instance URL
• keep the object target explicit through a bounded path template
• expose SOQL as a named capability rather than generic HTTP access to every endpoint
• make writes deliberate and object-scoped instead of allowing broad mutation coverage in the first pass

Action Model notes

At execution time, callers supply values by location:

• no extra inputs are required for describe-sobjects
• input.query.q for query
• input.path.objectApiName and input.body for create-record

Example object discovery request:

{}

Example SOQL request:

{
  "query": {
    "q": "SELECT Id, Name FROM Account LIMIT 25"
  }
}

Example record create request:

{
  "path": {
    "objectApiName": "Lead"
  },
  "body": {
    "LastName": "Nguyen",
    "Company": "Breakwater Ninja",
    "Email": "alex@example.com"
  }
}

For create-record, keep the body bounded to the specific object fields you intend to support in a given Harbor workflow.

Safety note for SOQL and writes

query is left automatic because it is still a read, but it should remain visible and reviewable since SOQL can access broad datasets. create-record stays on require_approval because it mutates CRM state and can trigger automation, assignment rules, and downstream business workflows.

Suggested operator workflow

1. Import the Salesforce Dock entry from Dock / Hub.
2. Configure the local Salesforce instance URL in Harbor Node.
3. Configure the local OAuth bearer token in Harbor Node.
4. Use describe-sobjects to confirm available object names.
5. Use query to validate the fields and object shape you need.
6. Keep create-record on require_approval unless there is a very clear local policy reason not to.

Suggested agent workflow

1. Inspect the existing Salesforce Harbor Port.
2. Inspect live actions and drafts.
3. Propose additional fixed Salesforce routes only when they remain bounded and reviewable.
4. Validate and test drafts.
5. Request publish instead of self-publishing unless Harbor explicitly allows it.

Agents should never:

• ask Harbor for the stored Salesforce token
• widen Salesforce into a generic tenant administration proxy
• add destructive or bulk mutation coverage without review
• hide the instance URL or object targeting behind arbitrary route input

Current update strategy

For now, Salesforce updates are manual:

• update the Dock / Hub Salesforce integration document in apps/hub/catalog/integrations/salesforce/salesforce-rest-api.json
• bump the manifest version when the action set changes materially
• re-import into Harbor or create new drafts from the updated Dock entry

Official reference starting points

• Salesforce REST API introduction: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_rest.htm
• Global sObject describe: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_describeGlobal.htm
• sObject basic information: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_sobject_basic_info.htm
• SOQL query resource: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_query.htm