Your WordPress and Salesforce data live in separate worlds
A new customer checks out in WooCommerce. That person needs to exist as a Contact in Salesforce, attached to the right Account, with the order value recorded as an Opportunity. Right now, one of three things happens: your team copies the data manually, you pay for a Zapier zap that breaks silently when Salesforce field names change, or the data never makes it across at all.
Manual entry doesn't scale. Zapier works until it doesn't, and when it stops you find out from a sales rep, not an alert. What you actually want is a direct call from WordPress to Salesforce the moment something happens, with the exact fields you control, driven by logic you wrote.
What most people do
A better way: direct Salesforce REST calls from inside a macro
TrueCommander's salesforce api request command handles the OAuth 2.0 Username-Password flow for you, caches the access token for 30 minutes per org and user combination, and auto-refreshes on a 401. You hit any Salesforce REST endpoint with any method. Every parameter supports {{placeholder}} substitution, so you store your credentials once as TrueCommander variables and reference them everywhere without repeating raw secrets in every step.
The token cache eliminates redundant auth calls. When a macro triggers salesforce api request multiple times in quick succession, each subsequent call within the 30-minute window reuses the cached token. A 401 from Salesforce triggers an automatic re-authentication before retrying the request, so token expiry never surfaces as an error in your macro logs.
How it works
{{sf_client_id}} and so on in every step that calls Salesforce, so you update them in one place if they ever rotate.{{placeholders}} in the -body parameter. The command resolves them at runtime and sends the exact payload Salesforce expects.| Detail | Value |
|---|---|
| Command name | salesforce api request |
-client_id | Connected App consumer key from your Salesforce org's App Manager |
-client_secret | Connected App consumer secret |
-username | Salesforce login username (usually an email address) |
-password | Salesforce password concatenated directly with the security token from your SF profile settings (no separator) |
-login_url | https://login.salesforce.com for production. https://test.salesforce.com for sandbox. Defaults to production. |
-sandbox | If true and no -login_url is set, uses https://test.salesforce.com automatically |
-api_version | Salesforce API version, e.g. v59.0. Defaults to v59.0. |
-method | REST method: GET, POST, PATCH, PUT, or DELETE |
-endpoint | Path starting with /, e.g. /services/data/v59.0/sobjects/Contact |
-body | JSON payload for POST, PATCH, or PUT. Supports {{placeholder}} substitution. Ignored for GET and DELETE. |
| Token caching | Access token cached 30 minutes per (org, client_id, username). Auto-refreshed on HTTP 401. |
| Placeholder support | All parameters resolve {{variables}} at runtime when used inside a macro |
| Can be used in |
Real example
A B2B WooCommerce store sells annual software licenses. Every new customer should become a Salesforce Contact and their first purchase should create an Opportunity so the sales team can see pipeline value in real time.
You create a macro that fires on WooCommerce's woocommerce_order_status_completed hook. Step one calls salesforce api request with -endpoint=/services/data/v59.0/sobjects/Contact, -method=POST, and a -body that maps {{billing_first_name}}, {{billing_last_name}}, and {{billing_email}} from the order. Step two reads the Contact ID from the response and calls salesforce api request again to create an Opportunity linked to that Contact, with the order total as the Amount field.
The whole macro runs in under two seconds. Your credentials are stored as variables and never appear in any macro step in plain text. The sales team opens Salesforce the next morning and every overnight customer is already there.