Salesforce API: Questions to Ask Before You Sign

A Salesforce API integration can connect your CRM to finance, marketing, support, commerce, or an internal application. It can also create a quiet source of operational risk if nobody agrees on the data, permissions, failure handling, and ownership before the work begins. If you are evaluating an integration project, the best questions are not only “Can you connect these systems?” They are “What exactly will you build, how will we know it works, and who will own it when something changes?”

Talk with an Omnivo Salesforce integration specialist before you approve a proposal and turn open technical questions into clear project decisions.

Start with the business outcome, not the endpoint

A partner may describe REST resources, webhooks, middleware, or an integration platform in the first meeting. Those details matter, but they should follow a measurable business outcome. A buyer should be able to state what the integration changes for a customer, employee, or finance team.

For example, “integrate our ERP with Salesforce” is not a useful scope by itself. “Create or update an account in Salesforce within five minutes of an approved customer record in the ERP, prevent duplicate accounts, and give finance a visible exception queue” is much closer to a testable outcome. The second statement gives the team something to design, estimate, test, and accept.

Ask the prospective partner:

Which business process is changing, and what is the current pain? What measurable result will tell us the project paid off? Which users or teams are in the first release? What should remain manual rather than being automated now? * What assumptions about our Salesforce org, source system, or data have to be verified?

These answers should appear in the proposal. Omnivo’s guide to Salesforce integration services is a useful companion when you want to separate the integration pattern from the business case. If a proposal jumps straight to technical features without defining the outcome, ask the partner to rewrite the scope before comparing prices.

1. What is actually in scope?

The phrase “Salesforce API integration” can describe a small, one-way data transfer or a multi-system program with real-time events, transformations, reconciliation, and a long-term support obligation. Those are very different projects. Ask for a system-by-system and object-by-object scope, not a sentence that leaves the detail for discovery after the contract is signed.

A useful scope should identify the systems involved, the Salesforce products and environments affected, the objects and fields exchanged, the direction of each flow, the trigger for each transaction, and the expected timing. It should also state what is not included. An exclusion is not a sign that the partner is being difficult. It is how you protect the first release from becoming an open-ended wish list.

Look for specific answers to these questions:

Which Salesforce objects, fields, relationships, files, or platform events are included? Which source-system records create, update, or delete Salesforce records? Is the flow one-way, two-way, scheduled, event-driven, or a combination? Are historical records, attachments, deduplication, or data cleanup part of this phase? Are middleware licenses, Salesforce licenses, sandbox work, and production deployment included? Which reports, dashboards, admin tools, and runbooks will be delivered? * Which requests are explicitly deferred to a later phase?

Compare the response with the level of detail recommended in a strong Salesforce implementation scope of work. A buyer should be able to trace every major line item in the price to a deliverable and every deliverable to an acceptance test.

2. How will authentication and access be secured?

Authentication answers how a system proves its identity. Authorization answers what that identity is allowed to do. A proposal that says “we will use OAuth” but does not explain the integration user, connected app, permissions, secret storage, and rotation process is incomplete.

Ask the partner to document:

Which OAuth flow fits the connection and why? Will the integration use a dedicated Salesforce integration user rather than a personal administrator account? Which objects, fields, records, and operations does the integration need? Where will client secrets, certificates, refresh tokens, or private keys be stored? How will credentials be rotated without taking the integration offline? How will access be removed when a vendor, application, or employee changes? * Which actions are logged so your team can trace a request to an application?

Least privilege should be visible in the design, not left as a promise. Salesforce’s guidance on using a dedicated integration user and OAuth client credentials explains why a separate identity for each application improves access control and auditability. Review the Salesforce integration user and OAuth guidance with your security owner and ask the partner to map the recommendation to your org.

Also ask what happens in a sandbox. Credentials, connected apps, callback URLs, certificates, and permission sets often differ across development, testing, and production. Environment-specific configuration belongs in the delivery plan, not in a last-minute deployment checklist.

3. Who owns the data and the source of truth?

Two-way integrations become difficult when both systems are allowed to change the same field. Before approving the build, create a simple data ownership matrix. For every important object and field, name the system of record, the system that may write it, the transformation rules, and the conflict rule.

Do not accept “Salesforce will be the source of truth” as a complete answer. Salesforce may own customer-facing account data while an ERP owns invoice status, or a commerce platform may own an order while Salesforce owns the relationship history. Ownership can differ by object and field.

Ask who approves the mapping and who can change it after launch. A technically correct integration can still create business confusion if no one is accountable for a definition such as “active customer,” “won opportunity,” or “fulfilled order.”

4. How will errors, retries, and duplicates be handled?

Every integration needs a failure design. Networks fail, APIs throttle requests, users enter incomplete data, permissions change, and downstream systems return errors. The important question is not whether the partner expects errors. It is whether your team can see, understand, and resolve them without guessing.

Ask for a plain-language answer to each of these:

What happens when the destination API is unavailable? Which errors are retried automatically, and with what backoff? How does the design prevent a retry from creating a duplicate? Where does a record go when it cannot be processed? Can an operator replay one failed transaction safely? How are permanent business errors separated from temporary technical errors? * What alert tells someone that a queue is growing or a flow has stopped?

Look for idempotency, correlation IDs, a dead-letter or exception queue, and a documented replay process. If the integration sends a customer update twice, the result should be a controlled update rather than two records or two outbound notifications. If the partner cannot show a failure example during the proposal review, ask for one before signing.

5. What will monitoring and support look like?

“The integration is live” is not the same as “the integration is being operated.” Buyers need to know what is monitored, who receives alerts, how quickly someone responds, and how the team investigates an issue across systems.

A credible support plan names the signals it watches. That may include authentication failures, API limit consumption, latency, queue depth, error rate, records processed, records rejected, and age of the oldest unprocessed item. It should also explain whether monitoring covers Salesforce, middleware, and the connected system or only one layer.

Ask these operational questions:

Who owns first response during business hours and after hours? What are the response and restoration targets for a failed integration? Where do alerts go, and who is on the notification list? What dashboard or report can our administrators view without vendor help? How are recurring failures analyzed rather than repeatedly dismissed? What changes require a release, and who approves them?

Use the proposed dashboard and alert examples in the evaluation. A screenshot with generic green status indicators is not enough. Ask to see the event, log entry, correlation ID, error detail, and replay action for a realistic failed transaction.

6. How will security, privacy, and compliance be tested?

Security review should cover more than the login flow. The integration may copy personal, financial, health, or commercially sensitive data into logs, middleware, backups, and notifications. Ask the partner to identify where data travels and where it is retained.

Clarify:

Which fields are transmitted, logged, cached, or stored outside Salesforce? Are sensitive values masked in logs and support screens? How long are logs and failed payloads retained? Which vendors or subprocessors can access the data? How are access reviews, vulnerability fixes, and incident notifications handled? Which compliance obligations apply to this project, and who validates them?

Ask for a threat model or security review appropriate to the project’s risk. This does not need to be a 100-page document for every integration, but it should cover trust boundaries, credentials, data exposure, privilege, abuse cases, and recovery. If your organization has legal or regulatory requirements, include the right security and compliance reviewers before the design is finalized.

7. What does testing prove?

Integration testing should prove business outcomes, not just that one API returned a successful response. Ask for a test plan that covers normal records, missing data, invalid values, duplicate attempts, updates, deletes, permission failures, timeouts, rate limits, partial outages, and replay.

Make the partner explain the environments and test data. Production data should not be copied into a sandbox casually. If masked or synthetic records are required, that work belongs in the plan. The test plan should also identify who supplies expected results and who signs off at each stage.

Acceptance criteria should be concrete. “The integration works” is weak. “A new approved account creates one Salesforce account within five minutes, maps the approved fields, records the external ID, and produces an actionable error when the required billing country is missing” can be tested. Connect each major requirement to an evidence artifact such as a test result, log, screenshot, or reconciliation report.

For a broader contract review, compare your acceptance criteria with the safeguards in Omnivo’s guide to Salesforce implementation proposal requirements.

8. What documentation and handoff will we receive?

An integration is not finished when the first production transaction succeeds. It is finished when your team can understand the design, perform routine administration, diagnose an exception, rotate a credential, and make a safe change.

Put the documentation deliverables in the agreement. At minimum, ask for:

An architecture diagram with systems, flows, trust boundaries, and environments Field mappings and transformation rules Authentication, permission, and secret-rotation procedures Monitoring definitions, alert routing, and escalation contacts Error catalog with remediation and replay instructions Deployment, rollback, and disaster-recovery procedures Test cases, acceptance results, and known limitations Recorded training or live enablement for admins and operators

Ask where the source files will live and who can edit them. Documentation stored only in a vendor’s private workspace is not a handoff. Your team should receive the configuration inventory and enough context to run the service if the original project team changes.

9. What happens when the project changes?

Good integration proposals make change visible. Requirements will change as users see the first workflow, but a change should have a clear impact on scope, cost, timing, security, and testing. Ask to see the change-control process before you need it.

The process should say who can request a change, how the partner estimates it, what approval is required, and how the team protects the committed release. It should also distinguish a defect from new scope. Fixing a deliverable that does not meet its acceptance criteria is different from adding another object or system.

Read Omnivo’s analysis of how Salesforce implementation scope creep starts alongside the proposal. If the partner refuses to name exclusions, change rules, or a path to end the engagement, treat that as a commercial risk rather than a minor contract detail.

10. Which partner questions reveal real capability?

Ask each finalist to answer the same scenario, not only to present its preferred tools. Give them a realistic failure: a source record is updated twice, Salesforce returns a limit error, and the downstream system has accepted one of the messages. Ask them to walk through detection, reconciliation, user communication, and recovery.

Then ask:

Which similar integrations has your team delivered, and what went wrong? Who will design, build, test, and support this specific project? What would you verify in our Salesforce org before estimating? Which part of this proposal is most uncertain? What will our team need to provide each week? What would make you recommend a smaller first release? Who owns the code, configuration, mappings, and documentation at the end? What support option is available after the initial warranty period?

Strong partners will identify assumptions and tradeoffs instead of pretending every unknown has a fixed price. They should be able to describe a safe first release, the evidence needed to expand it, and the skills your team will need to operate it.

A practical Salesforce API buyer scorecard

Before you select a partner, score the proposal against the same categories. A low price is not a saving if the integration has no replay path, weak access controls, or no owner after launch.

Final checklist before you sign

You do not need to know every Salesforce API detail to buy a sound integration project. You do need enough clarity to compare proposals and hold the chosen partner accountable. Before signing, confirm that the project has a measurable outcome, a bounded scope, a secure access model, a field-level data ownership decision, a failure and replay design, operational monitoring, meaningful tests, and a documented handoff.

Ask the partner to put open assumptions in writing. Resolve the assumptions that could change price, timeline, data exposure, or operational responsibility. If the proposal answers these questions plainly, you are evaluating a plan. If it avoids them, you are evaluating a promise.

Need a second opinion on an integration proposal? Explore Omnivo Digital’s Salesforce services or bring the scope to a strategy conversation before the project starts.

Salesforce API buyer FAQ

Is a Salesforce API integration the same as a Salesforce implementation?

No. An implementation configures Salesforce for users and business processes. An API integration connects Salesforce with another system or service. A project may include both, but the scope, testing, security, and support responsibilities should be separated so the integration does not disappear inside a general implementation estimate.

Should a buyer choose real-time integration every time?

No. Real-time processing may be useful for a customer-facing workflow, while a scheduled batch is simpler and sufficient for a nightly finance reconciliation. Choose the timing that the business outcome requires. Ask the partner to explain the tradeoff in cost, resilience, API consumption, and operational complexity.

What is the most important contract question?

Ask how the team will prove that each deliverable is complete and who owns the system after launch. Clear acceptance criteria and operational ownership expose gaps that a feature list or low project price can hide.