Akeneo
inbound
Bring paged product information into governed mapping and review.
Boundary: No approved live Akeneo instance has been connected.
Integrations
Connect Your Systems Without Handing Over Control
GearDock connects to PIM, commerce, CMS, cloud file, and SFTP systems through one platform rather than one-off scripts. Each provider states which direction data moves, how far we have proven it, and what it is allowed to do at the destination.
Your systems
- PIM / ERP
- Commerce
- CMS
- Files / APIs
Connection layer
- Connect
- Map
- Sync
- Review
Tenant-scoped processing
Authorization, capability checks, rate governance, checkpoints, retries, idempotency, conflicts, and append-only evidence.
Controlled outcomes
- Governed records
- Released packages
- Draft destinations
Can GearDock Connect to My Systems?
Sixteen provider profiles cover the common PIM, commerce, CMS, cloud file, and SFTP patterns. Connecting your own account still needs approved credentials, scope, and field mapping, which we set up with you.
How Are Connections Kept under Control?
The same rules apply to every provider: authorization, organization scope, approved mapping, resumable jobs, retries, a release check before sending, and a record of every delivery.
Provider Profiles
Every Provider, With Its Proof Level Attached
A profile means the connector is built and runs on the same platform as the others. It does not mean it is already connected to a live customer account, and it does not mean production traffic is switched on.
PIM
3 profiles- Protocol tested
- Protocol tested
Pimcore
bidirectional
Import product records and create unpublished outbound records after governed preflight.
Boundary: Outbound support is create-only and unpublished.
- Protocol tested
Generic REST PIM
bidirectional
Connect a reviewed REST profile when a PIM exposes a stable paged contract.
Boundary: Each customer contract, authentication method, mapping, and endpoint allowlist requires review.
Commerce
4 profiles- Development-store proven
Shopify
bidirectional
Discover store products and create or update Shopify products through the durable integration plane.
Boundary: Writes are DRAFT only. There is no live-publication or remote-delete path.
- Real local-provider proven
WooCommerce
bidirectional
Import products and write reviewed product records as drafts.
Boundary: Variation authoring is intentionally bounded.
- Real local-provider proven
Magento Open Source
bidirectional
Import Magento products and write disabled, non-visible product records.
Boundary: Configurable children and media authoring are bounded.
- Contract tested
BigCommerce
bidirectional
Import products and write records with storefront visibility forced off.
Boundary: Live sandbox qualification awaits customer credentials.
CMS
4 profiles- Real local-provider proven
WordPress
bidirectional
Read posts or pages and create reviewed content as drafts.
Boundary: Featured-media binary upload remains an extension point.
- Contract tested
Webflow CMS
bidirectional
Read CMS items and write through the staged, non-live endpoint.
Boundary: Live CMS qualification requires a CMS-scoped token, site, and collection.
- Contract tested
Contentful
bidirectional
Read entries and create draft entries without calling publish.
Boundary: Asset and rich-text authoring remain extension points.
- Contract tested
Sanity
bidirectional
Read governed content and write only to draft document IDs.
Boundary: Schema discovery is sampling-based and requires project access.
Cloud Files
4 profiles- Protocol tested
Google Drive
inbound
Read an explicitly authorized file, folder, or subtree into the organization workspace.
Boundary: Live use requires an approved customer OAuth configuration.
- Protocol tested
Google Sheets
inbound
Read an explicitly selected spreadsheet, sheet, and optional range.
Boundary: Live use requires an approved customer OAuth configuration.
- Protocol tested
Microsoft OneDrive
inbound
Read a tenant- and drive-bounded file, folder, or authorized subtree.
Boundary: Live use requires an approved Microsoft OAuth configuration.
- Protocol tested
Microsoft SharePoint
inbound
Read from an explicitly bounded site, library, file, folder, or subtree.
Boundary: Live use requires an approved Microsoft OAuth client and SharePoint site.
Protocol
1 profile- Protocol tested
SFTP
bidirectional
Read from a bounded directory and deliver files through an atomic outbound drop.
Boundary: No approved external partner endpoint has been connected.
Customer Configuration and Activation
None of these profiles is switched on for public production traffic. Connecting your own account requires approved credentials or an OAuth grant, a defined scope, field mapping, and endpoint settings. Nothing on this page means a provider is already connected to a live customer account.
Proof Levels
Tested and Live Are Not the Same Thing
Most vendors show one logo grid where everything looks equally finished. The label below travels with each provider so you can tell what has actually been run against a real system.
- Development-store proven
- We have run it end to end against a real account with the provider, on a development store or workspace.
- Real local-provider proven
- We have run it against the provider's own software, installed and running in an isolated environment of ours.
- Protocol tested
- We have run it against the real protocol or client, using a controlled test server rather than the provider's own software.
- Contract tested
- We have tested the adapter's behavior and security boundaries without connecting it to a live account.
To be specific: Shopify has been run end to end against a real development store and only ever creates drafts. WordPress, WooCommerce, and Magento have been run against the provider's own software in an isolated environment of ours. The rest sit at protocol or contract level until an approved environment is available to test them further.
The Platform Underneath
The Hard Part Starts After the API Call
Anyone can make one API call succeed. A real integration has to survive rate limits, half-finished runs, restarts, conflicting edits, and several customers sharing the same workers without mixing data or crowding each other out.
It Finishes What It Starts
- Work runs in the background and picks up where it left off
- Retries tell a temporary failure apart from a permanent one
- Rate limits follow what each provider allows
- Idempotency means a repeat run converges rather than duplicating
- Checkpoints are written only after an item is safely recorded
- Crash recovery restarts from the last safe checkpoint, not the beginning
One Customer Cannot Affect Another
- Provider bulkheads keep one struggling destination from spreading
- Tenant fairness stops a single large catalog from taking over the worker
- Organization scope is applied again on every connection, job, item, and event
- Customer configuration is required before any provider traffic runs
- Credentials are stored as protected references, never copied into a job
- Production and provider traffic stay behind explicit activation controls
You Can See What Happened
- Every job, item, delivery, API request, and decision is recorded and never edited
- Conflicts are shown to an operator instead of being overwritten
- Dead-letter handling catches work after its attempts run out
- Cancellation takes effect at a safe boundary rather than mid-write
- Inbound webhooks are safe to replay and are recorded on receipt
- Outbound webhooks are signed, retried, rotated, and logged per attempt
Five Ways to Connect
Pull Data in, Push Content Out, or Call the API
The same organization scope and the same delivery records apply whether a person starts a sync from the workspace or another system talks to GearDock on its own.
Pull Records In
Bring products in from a connected system, page by page, into mapping, checking, matching, and review.
Push Content Out
Send only currently released records, and only into a destination's draft or unpublished state.
Inbound Webhooks
Check the signature before anything else, ignore duplicates, and keep a receipt for each one.
Outbound Webhooks
Sign each delivery, rotate the secret, retry temporary failures, and keep every attempt.
Public REST API
Use scoped keys you can rotate, with rate limits, safe retries, and a record of each request.
Capabilities at a Glance
The Same Controls on Every Connection
- Inbound synchronization
- Outbound synchronization
- Inbound webhooks
- Outbound webhooks
- Public REST API
- Background execution
- Retries and rate limits
- Idempotency
- Checkpoints
- Crash recovery
- Dead-letter handling
- Provider bulkheads
- Tenant fairness
- Append-only audit evidence
Private Beta
Tell Us What You Run Today
List your systems, which way data needs to move, and how much of the catalog is involved. We will tell you what is ready now, what needs configuration, and what is not proven yet.