Wirekit

Wirekit is a hosted data-connection service for developer teams, delivered through a web console and a REST interface: hosted connectors pull records from business systems, field mapping reshapes them, and scheduled syncs deliver the result into internal workflows. The delivery type is software; the official entry point is wirekit.example.

The product addresses developers who maintain internal systems, plus platform and data engineering teams, and is purchased for business use. The site and docs are written for an engineering reader and are not segmented by industry; company-size mix and buying roles are not described publicly.

A platform engineer needs records from one business system delivered into an internal service on a regular basis: configure a connector and a field mapping, set a schedule, and end up with a repeatable sync job their own tools can also call.

The site and docs describe the prior approach as writing a sync script per system and handling pagination, retries and credential rotation in-house. The stated difficulty is scripts scattered across repositories and failures that are hard to trace. This is the vendor's account; no user interviews support it.

Product proposition: hosted connectors, field mapping and scheduled syncs replace hand-written sync scripts, while a REST interface lets existing tools trigger the same job. The docs demonstrate these capabilities; engineering time actually saved is unevidenced and remains a claim.

The docs state that the console and API reference are English only, list connectors by source-system category and name two hosted regions. Dedicated deployment, service-level commitments and industry restrictions do not appear on public pages, and absence is not read as unsupported.

Interface language

English

Entry points

Web console, REST interface, CLI

Hosted regions

Two regions listed in the docs

Service-level commitment

Not disclosed

Checked 2026-09-17: the site offers open self-serve signup, and the docs, status page and pricing page all load. No shutdown notice or waitlist was shown. Only public web entry points were checked — the console was not entered and API availability was not tested.

Core delivery is hosted connectors, field mapping and scheduled syncs, which produce data written into a target system; the REST interface is a second entry to that same delivery, letting outside tools trigger a run. Run logs, retry settings and alerts support troubleshooting rather than completing the job.

Documented inputs are source-system credentials, connection settings, field-mapping rules and a schedule; some connectors also accept a CSV upload for a one-off import. Public docs do not state a per-run record ceiling or an upload size limit.

The output is records written into the target system under the mapping, plus a structured log for each run carrying a run id, processed counts, failed rows and error reasons. The docs show one JSON run response, which confirms field names and status values; actual data quality was not verified from a sample.

One core path: create a connection → configure the field mapping → dry-run and read the log → set a schedule or trigger through the API → watch failures and retry. The docs present this order; nothing was executed under an account, and console steps come from documentation screenshots.

1. 1Developer

   Create a connection

   Pick a source connector in the console, supply API credentials and authorize write access to the target.

2. 2Developer

   Map the fields

   Map source fields onto target fields and set required fields and type conversions.

3. 3Developer

   Dry-run

   Run a small batch and read processed counts and failed rows in the run log.

4. 4Developer

   Schedule or trigger

   Set the sync cadence, or let your own service trigger the same job through the REST interface.

5. 5Platform team

   Monitor and retry

   Spot failures in the run list and alerts, and re-run under the connector's retry policy.

The /docs home explains the concepts and the quickstart; each connector page carries authorization steps, a field table and a sample request; the console run list holds logs and retries; /pricing explains metered pricing and the monthly minimum. Console screens were seen only in documentation screenshots.

The docs state that creating a connection requires an account, source-system API credentials and write access to the target, and that calling the REST interface requires a key generated in the console. Billing starts at the first successful production run; the trigger is recorded under initial payment trigger.

The payer is the team that owns the workspace, with billing usually set up by a platform or engineering lead; the users are the developers who configure connections and call the API. What is bought is metered connector runs and API access — seats are not priced, so headcount does not move the bill.

Billing is metered: the unit is one successful sync run, settled each calendar month against a monthly minimum. API-triggered runs meter exactly as scheduled ones do. The docs say failed runs are not metered; whether retries are metered is not stated.

Billing model

Usage-based with a monthly minimum

Billing unit

One successful sync run

Settlement

Per calendar month

Seat fee

None

Failed runs

Not metered, per the docs

The pricing page lists three tiers: Starter, Scale and Enterprise. The first two are self-serve; Enterprise is described as an annual commitment quoted on request. All three meter the same way and differ in monthly minimum, per-run rate and operational entitlements.

Two self-serve prices are published: Starter carries a USD 49 monthly minimum with runs beyond it at USD 0.004 each, and Scale a USD 249 minimum at USD 0.0025 per run. Enterprise shows no price and is marked as an annual commitment quoted on request. Taxes are excluded.

The pricing page offers an annual option: a Starter annual commitment of USD 490 charged once and covering twelve months, an equivalent of USD 40.83 per month — not a monthly charge of USD 40.83. The per-run rate is unchanged; the discount applies to the minimum only.

Volume included in the minimum follows from the per-run rate: 12,250 runs a month on Starter and 99,600 on Scale, with anything beyond charged run by run. The docs add that concurrency and API rate limits differ by tier. Whether unused volume rolls over is not published.

Entitlement differences sit in operations: Scale adds a sandbox, custom retry policies and run-log export, while Enterprise additionally lists single-tenant hosting and audit logs. The connector catalogue and field-mapping capabilities are presented as identical across tiers; none of this was tested under an account.

Docs and the pricing page state that signup opens a sandbox for test runs with no card required, and that the first 1,000 runs in the opening calendar month are not billed. Whether charging starts automatically afterwards is not stated; the minimum applies from the first billing cycle.

The first charge appears when the free run allowance is exhausted and a sync moves from sandbox to production: the console asks the user to choose a tier and confirm the monthly minimum, then bills monthly. The trigger is run volume and environment, not seat count or a feature unlock.

Estimated website visits for August 2026 are 90,000, covering global desktop and mobile web and counting repeat visits by the same person. The figure is a traffic model estimate — not unique visitors, not page views, and not API calls.

Milestones recorded in the changelog and company page: first public availability on 2023-09-04 with the first five connectors; the REST API and CLI in May 2024; a move to per-run pricing with a monthly minimum in March 2025; and the sandbox in February 2026. Sequence does not establish cause.

2023-09-04

First public availability with five connectors

May 2024

REST API and CLI released

March 2025

Moved to per-run pricing with a monthly minimum

February 2026

Sandbox environment released

The company page lists a team of 15, recorded on 2026-09-10, weighted towards engineering with documentation and support roles alongside and two founders. Whether contractors or part-time staff are included is unstated. This is a company figure, not the product's dedicated staffing.

Team size

15 (recorded 2026-09-10)

Main functions

Engineering, documentation, support

Founders

Two listed on the company page

Scope

Company-level; contractors and part-time not separated

Monthly recurring revenue for August 2026 is estimated at USD 35,000. The figure is modeled from metered usage rather than disclosed by the company, and excludes one-off migration spend. Read it separately from period revenue, under its own definition.

Website visits rise from 75,000 in July 2026 to 90,000 in August: an absolute increase of 15,000 and +20.0% month over month. Both months come from the same traffic estimate on the same global basis with no missing month, and the change itself remains an estimate.

Three acquisition activities are observable: per-connector integration pages and documentation, a steadily updated changelog and engineering blog, and a handful of directory and marketplace listings. No paid advertising records appear in the ad libraries checked, and public material cannot separate what each channel contributes.

The site footer links a brand account and the engineering blog's RSS feed; the company page separately lists two founder accounts as team members. No evidence of a commercial arrangement with third-party creators was found, and links or mentions are not treated as payment.