In the business software
The team creates a vehicle record and fills in its price, mileage, specifications, status, seller and gallery. Spider VO gathers this work in one place and distributes the inventory to the intended channels.
In practice — 05 · Custom-built connector
The inventory changes in the CRM. The site follows.
For MCT Consulting, we connected Spider VO to the public catalog. Each cycle reads the vehicles, adapts their data, copies their photos and updates the site, with checks that protect the inventory.
A custom-built connector
Two tools keep their roles. The connector moves the right data.
Line-of-business software knows the inventory. A website knows how to present it. Between the two, the connector reads the source’s format, applies the company’s rules and hands the site data it can publish.
At MCT Consulting, Spider VO remains the operational starting point. The site receives the vehicles, their details, the designated contact and their photos. An update therefore starts in the tool the team already uses.
- 01
Read
Get the feed the source tool provides.
- 02
Translate
Map each field to the site’s model.
- 03
Check
Verify the content before changing the catalog.
- 04
Log
Record the result and errors of each cycle.
Custom work often starts right here: between two useful tools that must share information according to the real rules of the business.
The starting point
Spider VO runs the inventory. The site helps the customer choose.
On the MCT Consulting site
The visitor browses the available vehicles, opens a detailed listing, looks at the photos and contacts the right team. The site turns operational data into listings customers can browse and use to choose a vehicle.
These two uses share the same vehicle. The connector maintains that link: a source record becomes a web listing, and each change then reaches the catalog in a following cycle.
One source, several presentations. Inventory is entered in Spider VO. The site then chooses the form, filters, addresses and journey that suit its visitors.
The relay
The connector gets a stable path to the source.
Access to the Spider VO feed goes through a controlled gateway. The application hands it a request, the gateway forwards it to the authorized source, then returns the response to the connector.
- MCT app
- Gateway
- Spider VO export
- Gateway
- MCT app
One access point to monitor
The route to the source has one identified entry point.
Access suited to each branch
Each branch connects to its own feed.
An infrastructure detail that stays backstage
The visitor sees a catalog. The team keeps the access and configuration in the intended environment.
From export to listing
Moving the file is one step. Publishing a reliable catalog takes five.
1. Read the feed
The connector requests the export and recognizes each vehicle by a stable reference. It receives the business fields and the ordered list of photos.
Source read
2. Adapt the data
Spider VO’s format becomes the site’s model: make, model, price, mileage, fuel type, transmission, description, branch and seller land in their designated slots.
Data translated
3. Compare with the catalog
Existing listings are updated using their reference IDs. A new reference creates a listing. A vehicle that left the feed takes the designated status after the consistency check.
State compared
4. Copy the photos
The site verifies each file as an image, copies it into its own storage and keeps the gallery order. A replaced photo address is detected even when the total count stays the same.
Gallery copied
5. Write the result
The cycle keeps its status, duration and totals. An error joins the same history so the team knows where to pick up.
Result logged
The connector therefore handles two contracts at once: the format machines expect and the rules the business expects.
The safeguards
A reliable automated process also knows when to stop.
An external feed can arrive empty, incomplete or late. An image URL may return the wrong content. Two sync runs may overlap. The connector then decides how to preserve a usable state.
| Situation | Connector’s decision | Effect on the catalog |
|---|---|---|
| The feed arrives empty | The cycle stops before any change | The published inventory stays in place |
| A change looks abnormal | The change is suspended | The team examines the feed before resuming |
| Two cycles overlap | Only one continues processing | Each branch keeps a consistent sequence |
| A gallery takes longer | The rest waits for a following cycle | The retry gradually completes the gallery |
| A photo returns different content | The file is discarded | Storage receives only images |
| A copy fails | The gallery is queued for another attempt | A new cycle can complete it |
Preserve before fixing. Surprising source data becomes an event to examine. The last consistent state remains the basis of the catalog.
The behavior described here was verified in the private MCT Consulting repository. Thresholds, access and addresses stay confidential.
The delivered scope
Photos follow the feed. Authorized users upload videos separately.
In the delivered integration, the Spider VO automation covers listings and their photos. The connector checks, then copies the images the feed exposes.
Videos use a separate workflow: an authorized user adds them from the MCT interface. Each medium thus takes the path intended for its origin, size and rights.
From Spider VO
Vehicle listingspecificationsstatussellerphotos
From the MCT interface
Videos and media added by authorized users
This boundary describes the scope in production at the time of our October 2, 2026 review.
The business result
The team works in its own tool. The catalog keeps pace.
When the handoff depends on a human action
The same listing must be re-entered, photos must be transferred and every sale must reach the site. Catalog quality then depends on a chain of repeated manual steps.
When the handoff becomes a system
The team keeps the inventory in Spider VO. On each cycle, the connector compares, adapts and copies. The site receives new vehicles, changes and stock removals validated by the checks.
The inventory keeps one starting point
Operational data starts in the business software already in use.
The catalog follows several branches
Each branch keeps its vehicles, sellers and history.
An incident leaves a trace
The team finds the cycle’s status, its totals and the error that needs action.
The result is a catalog that follows the business. The value of custom work lies in that steady movement and in the decisions made when the source sends unexpected data.
A transferable skill
The format changes. The question stays: which data should reach which tool?
Rental calendars that share their booked nights
On a rental site, we also connected an external calendar to the public calendar. Booked dates are synced to the site, the interface shows how fresh the feed is and keeps the last reliable state when a third party responds badly.
The platform reading the calendar controls how often it checks for updates. The screen says so plainly: the rhythm is part of the connector’s contract.
Dates read · limited data · freshness shown · last state kept
A call that reaches the calendar, the CRM and the team
For our AI phone answering service, the same principle connects the conversation to the calendar, the CRM, messages and the team. The rhythm changes; each tool receives the data and the action that belong to it.
Automotive, rentals or telephony: a useful connector starts from the real process, picks a source and writes down the expected behavior for every deviation.
The signals
Your daily routines often point to the integration to build.
Consider a connector when several of these situations are part of everyday work:
- You re-enter the same information in two programs.
- A change must reach several sites, teams or branches.
- A CSV or XML export regularly passes between two people.
- Photos or documents follow a separate transfer from their record.
- A business rule goes beyond the options of the connector the vendor provides.
- A sync error only becomes visible after a customer calls.
- One tool holds the reference data and another presents or enriches it.
- The company grows and each new location repeats the same setup.
The right level of custom work depends on the need. A native connector covers a standard exchange. An automation tool chains a few steps. Dedicated development makes sense when the format, volume, permissions or error rules truly belong to your business.
The useful brief
Seven answers already sketch the architecture.
01Where does the reference data originate?
Name the tool that is authoritative for each object: customer, product, inventory, price, availability, document or media.
02Which way does it flow?
One direction, a round trip or several destinations call for different rules.
03How often should the data update?
An immediate action, a regular cycle and a daily catch-up meet distinct needs.
04Which fields should be transferred?
A useful list limits exposure, transformations and drift.
05What should happen when data is empty or surprising?
Keep, suspend, complete or alert: each family of data deserves a written answer.
06Who can trigger, rerun and view the history?
Permissions cover everyday operation as much as incidents.
07What proof confirms the last successful run?
A status, a date, totals and a usable error give the team a point to resume from.
These answers turn “connect our tools” into a scope everyone can understand, price and verify.
Your next handoff
Two tools that should already be working together?
Describe the source data, the tool that should receive it and the step your team repeats today. We will help you choose between changing a setting, using an existing connector, automating the task or building a custom integration.
Describe the tools to connectSee our work
The project brief asks about the process, users, data and external services. You can answer in your own words.
Public sources
MCT Consulting’s specific behavior was verified in its private GitHub repository on October 2, 2026. This page describes the route and its safeguards. The code, access, addresses, thresholds and client data stay in their own environment.
- Spider VOofficial presentation of the platform, inventory, CRM, multi-channel publishing and connected tools
- Caddyofficial documentation of the
reverse_proxyrelay, used as the general definition of the mechanism - Supabaseofficial documentation on scheduling functions and tracking recurring tasks
- IETFthe iCalendar standard used for the rental calendar parallel
- MCT Consultingthe public catalog