REST API: A simple, resource-based API ideal for real-time integration. You can use REST endpoints to query, create, update, or delete FieldKo records over HTTP. For example, a GET request to /services/data/v57.0/query?q=SELECT+...+FROM+Visit__c could retrieve Visit records, and a POST to /services/data/v57.0/sobjects/Visit__c/ could insert a new Visit. The REST API supports JSON and XML, making it useful for web and mobile apps​. This is perfect for pulling FieldKo data into a dashboard or pushing a single record from an external system in real time. Benefit: REST is straightforward and stateless, suitable for integrations needing quick responses.

Bulk API: Designed for high-volume data loads. Bulk API (including the newer Bulk API 2.0) lets you insert or query large batches of FieldKo records asynchronously. Instead of sending one record at a time, you send a batch (for example, thousands of survey results in one go) and Salesforce processes it in the background. Use Bulk API for mass export/import, migrations, or nightly sync jobs involving FieldKo data. For instance, you might export all FieldKo survey responses weekly via Bulk API to a data warehouse. Bulk API is optimised for 10,000+ records and can handle up to 15,000 batches in a 24-hour period, with each batch supporting up to 10,000 records or a 10MB CSV file​. Benefit: Bulk API is very efficient for batch processing – it greatly reduces API calls when dealing with large datasets by processing records in bulk asynchronously.

Tooling API: A specialised API for Salesforce metadata and developer tooling. While not typically used for day-to-day data transfer, Tooling API can be useful for advanced scenarios, like retrieving FieldKo’s custom object definitions, automating org setup, or building custom admin tools. For example, a developer could use Tooling API to query which FieldKo custom fields exist or to deploy an Apex trigger that interacts with FieldKo records. Use Tooling API when you need fine-grained access to org metadata or to perform operations that Metadata API might handle in bulk​. Common use cases include integrating with source control, continuous integration deployments, or manipulating Apex classes/triggers related to FieldKo​. Benefit: Tooling API provides insight into the Salesforce org’s configuration and is mostly used by developers for automation and DevOps, rather than for everyday data syncing.

Using REST API for FieldKo records: You can use the SOQL query resource or the sObject resource. For example, to fetch all “Visit” records updated today, you might call:
​GET /services/data/v57.0/query?q=SELECT+Name,+Status__c,+Date__c+FROM+Visit__c+WHERE+LastModifiedDate=TODAY
(This would return a JSON with the records). To create a new record, you could do a POST to /sobjects/Visit__c with a JSON body. The key is to use FieldKo’s object API names and field API names, which you can find by viewing the object in Salesforce Object Manager. No special API – just use the standard Salesforce object naming.

Using Bulk API for large exports/updates: If you need to extract a lot of FieldKo data (say all surveys from last year) or load a large batch of new records into FieldKo, Bulk API is ideal. You would create a Bulk job, submit batches of records (e.g. CSV files of survey data), and then Salesforce will process it. On completion, you can retrieve the results (successes and errors). Many ETL tools and integration platforms can use Bulk API behind the scenes. Bulk API is also great for scheduled nightly syncs – e.g. dumping all new FieldKo “Inspection” records of the day to an external database for reporting. Keep in mind Bulk API’s limits (15k batches per 24 hours, 10k records per batch as noted) when planning your jobs​. Also note that Bulk queries have some restrictions on query complexity and might return data in batches that you need to consolidate.

Using Tooling API for FieldKo metadata: Most FieldKo customers won’t need Tooling API, but if you’re developing custom extensions or tools, it can be handy. For example, you could query the Tooling API’s CustomObject or CustomField objects to dynamically discover FieldKo’s object schema (like to generate dynamic forms based on FieldKo fields). Or use Tooling API to run Apex scripts that involve FieldKo objects (by creating an Apex anonymous execution). These are advanced use cases – typically only Salesforce developers working on the org would do this. Standard reporting or integration tasks do not require the Tooling API.

Extracting FieldKo Data for Reporting or BI: Many customers want to include FieldKo’s inspection or survey data in external reports or business intelligence tools. Using the REST API or Bulk API, you can pull data out of Salesforce on a schedule. For example, you might run a nightly job that queries all new inspection results from FieldKo and writes them to an on-premise SQL database or a data lake for analysis. If the data volume is small (a few hundred records a day), a REST API script that queries and pages through results is fine. For larger volumes, use Bulk API to do a mass query and download the results in CSV format. This way, you can create consolidated reports combining FieldKo data with data from other systems. Many ETL tools and middleware (like MuleSoft, Boomi, etc.) have Salesforce connectors that make this easier – you’d configure a SOQL query to fetch FieldKo object records and then transfer them to your target system.

Pushing External Data into FieldKo: You might have other systems (ERP, HR system, IoT sensors, etc.) that need to send data into FieldKo (which is Salesforce) to trigger field processes or to be available on mobile forms. With the Salesforce APIs, you can create or update FieldKo records programmatically. For instance, imagine you have an ERP that approves a work order – you could have it call the Salesforce REST API to create a corresponding “Visit” record in FieldKo so that a field agent can see it in their checklist. If doing this in real-time, a direct REST API call on record change is great. If doing in batches (say, syncing a list of assets or sites nightly), Bulk API could load thousands of records in one job. Because FieldKo is just Salesforce data, you can even use Salesforce’s own integration features like External Services or Platform Events to facilitate this (advanced scenario: an external system could send a Platform Event that an Apex trigger in FieldKo’s package subscribes to, thereby kicking off an in-app process).

Automating Bi-Directional Syncs: In some cases, you might want a two-way sync between FieldKo and another system – for example, syncing customer or location info, so that both systems have the latest data. While Salesforce doesn’t have a built-in two-way sync tool, you can implement this with a combination of API calls and perhaps middleware. For example, you could use a scheduled job that calls Salesforce REST API to get updated FieldKo records (modified since last run) and updates your other system, and vice-versa calls to update FieldKo with changes from the other side. Salesforce APIs support filtering by date (e.g. using SOQL WHERE LastModifiedDate > X), which helps in incrementally pulling just changed data. For near real-time sync, you might use the Streaming API (PushTopic or Change Data Capture) to receive instant notifications of changes in FieldKo objects, then call an external API – or the external system might send outbound messages/webhooks to Salesforce. There are also iPaaS solutions (Integration Platform as a Service) that can listen and sync for you with low-code. The key point: anything that needs to stay consistent between FieldKo and another system can be kept in sync using the API – just design carefully to avoid infinite update loops and use an external ID or unique identifier to match records.

Triggering External Actions from FieldKo (and vice versa): Perhaps you want that when a FieldKo inspection is marked “Complete”, an external system is notified to generate an invoice. Salesforce’s API can be invoked from inside via Apex callouts – or simpler, you can use Salesforce Outbound Messages or Platform Events. While this is slightly out of scope of using the standard APIs directly, it’s good to know FieldKo (being on Salesforce) can participate in event-driven integration. For example, a FieldKo completion could fire a Flow that calls an external REST API (Salesforce can do HTTP callouts from flows now) to trigger the invoice system. Conversely, an external system can call Salesforce APIs (as discussed) to update FieldKo records to kick off in-app workflows. Essentially, the APIs enable FieldKo to be part of a larger automated process across your business.

Daily API Call Limits: Every Salesforce org has a limit on the number of API calls per 24-hour period, which depends on your edition and number of user licenses. FieldKo doesn’t have separate limits – it relies on the Salesforce org’s limits. For example, for an Enterprise Edition org, the base limit is 100,000 API calls per 24 hours, plus an additional 1,000 calls for each Salesforce user license in the org​. So if you have 15 users, that’s 115,000 calls per day. (Different license types contribute different amounts; e.g. a Force.com Platform license also typically adds 1,000, etc.) If you need more, Salesforce offers API call add-on packs, but most FieldKo customers find the default ample. Monitor your API usage in Salesforce Setup (there’s an “API Requests, Last 24 Hours” gauge) especially after you first deploy a new integration, to ensure you stay within limits. If you approach the limit, you may need to optimize or throttle your external calls.

Bulk API Limits: Bulk API calls don’t count in the same way as REST calls, but they have their own quotas. You can submit up to 15,000 batches per rolling 24 hours across Bulk API 1.0 and 2.0​. Each batch can contain up to 10,000 records. That means theoretically you could load 150 million records a day (which is far beyond typical usage). Also, Bulk queries (for extracting data) have limits on the number of records they return per batch. In practice, if you are doing nightly syncs with Bulk API, you’ll seldom hit these Bulk-specific limits, but it’s good to know they exist. If you do a massive one-time migration of FieldKo data (say importing millions of legacy inspection records), plan it in chunks and monitor batch usage.

Concurrency and Miscellaneous Limits: Salesforce also limits concurrent long-running API requests. For example, you can have up to 25 concurrent REST calls running longer than 20 seconds in a production org​. If you have an integration that makes many simultaneous calls (e.g. 50 threads all calling at once), you might hit this and get some errors to back off. Also, queries have a timeout (generally 2 minutes for API queries) – a very complex SOQL query might fail if it runs too long. To avoid issues, ensure your SOQL queries are selective (use indexes or filters) and try not to do huge data dumps via the REST API in a single call (better to use Bulk API or break into smaller chunks).

API Governance Best Practices: Try to design your integration to be efficient with calls. For instance, instead of retrieving one FieldKo record at a time in a loop (which could use 100 calls for 100 records), use a SOQL query to fetch multiple records in one go, or use the REST API’s Composite batch call to combine multiple operations into one request. If pushing data, you can use the REST API’s Composite Tree to insert, say, 50 records in one call. This helps stay within limits. Additionally, caching or storing data externally can reduce repetitive calls (for example, caching reference data like lists of stores or assets rather than querying them from Salesforce repeatedly).