Implementation FAQ

The traditional planning baseline below assumes that the integration team is learning the APIs and writing most of the code without AI or an existing Voodoo integration example. The phases can overlap:

• Pilot (2–4 weeks) — Deploy a Starter Kit, validate the workflow, and measure baseline improvements.
• Integration (2–6 weeks without AI) — Connect your WMS/ERP to the Voodoo API, map locations, and configure sequences.
• Rollout (1–4 weeks) — Scale from pilot zone to full deployment, train operators, and optimize.

Those numbers are useful for traditional project planning, but they are not a lower bound. Starting from a published integration example and working iteratively with the Voodoo Oracle can reduce the software-development portion dramatically. With clear requirements, platform access, and a close example, a first working version may be produced in hours rather than weeks.

Production still requires human review, access to the WMS or ERP, realistic test data, security approval, failure testing, operator validation, and rollout planning. AI accelerates discovery, coding, tests, documentation, and troubleshooting; it does not eliminate those safeguards.

Use the Voodoo Oracle as an engineering partner, not a one-question search box. Begin with your WMS or ERP, the event that should trigger a light, your Voodoo deployment, authentication method, preferred language, callback requirements, and production constraints. Ask the Oracle to question you about missing requirements before it writes code.

Then ask for the complete implementation: project structure, dependency files, environment-based configuration, API client, mappings, retries, timeouts, idempotency, logging, health checks, tests, deployment files, and operator documentation. Do not stop at a short code snippet.

Run the generated code against a test account, give the Oracle the exact errors and test results, and keep following up until the tests pass and the deployment procedure is repeatable. Finally, have a qualified person review security, credentials, error paths, and business rules before production.

Yes, and you should check before starting from scratch. Voodoo has published reusable examples for QuickBooks Online, Manhattan Active WM, Oracle NetSuite WMS, Oracle Fusion Cloud WMS, Extensiv 3PL Warehouse Manager, ShipStation, and Odoo.

Browse the Integration Examples to read about each approach and open its source repository. Fork the closest project, keep the working transport and safety patterns where possible, and customize the event and location mappings for your operation.

If you add a reusable mapping, test, deployment improvement, or bug fix, consider contributing it back through the repository or sharing it with Voodoo Support. Remove credentials and customer data before publishing anything.

Your IT team needs to provide:

• Network access — Turbos need Wi-Fi (2.4 GHz recommended) with reliable coverage in the deployment area.
• Firewall rules — If you are starting with www.voodoodevices.com, outbound HTTPS on port 443 is probably already allowed. If your network blocks it, IT will need to allow that traffic.
• API access — Almost every WMS or ERP can make the HTTP calls needed to use the Voodoo API. The main job is figuring out where in your system to add that call, how that platform handles it, and which vendor documentation or scripting guide explains the setup.

Yes. Voodoo integrates with any WMS that can make HTTP calls — SAP, Oracle WMS, Manhattan, Blue Yonder, Infor, homegrown systems, and more. The preferred option is the REST API for production workflows, while the QueryString API is the simplest path when you only need a URL call and minimal HTTP support. If your WMS supports scripting or webhooks, you may reach a first working integration in hours when a suitable example, platform access, and test environment are already available.

Big Block is the server software product that manages Cloud Display Devices and Turbos. www.voodoodevices.com is Voodoo's hosted (multi-tenant) Big Block instance running on AWS — it's subscription-based, supports up to 50 devices, and requires no infrastructure management.

Self-hosted Big Block is available through a perpetual license. You deploy it on your own infrastructure (public cloud, VPC, on-premise data center, or hybrid). It provides lower latency (~0.9s vs ~1.3s), unlimited device capacity, full Sequencer support, and complete data control.

You can start on www.voodoodevices.com and migrate to self-hosted Big Block later — the API is identical.

There's no hard limit. Big Block servers are sized by deployment — a standard Big Block handles up to 100 Turbos with 5,000 devices, and larger configurations are available.

No. Seldom used locations may not need devices. A single device can be associated with multiple locations (e.g., rack, shelf, bin). You can also use the Location Alias API to map multiple logical names to a single device — useful when your WMS uses different naming conventions.

Three options, depending on your workflow:

• Button press — Turbos have a built-in button. Operators press it to acknowledge a pick.
• Barcode scan — The operator scans a confirmation barcode, and your WMS sends a clear command to the device.
• Automatic timeout — Configure a sequence to auto-advance after a set duration (useful for put-to-light).

For closed-loop workflows, button press or barcode scan is recommended. See the Closed Loop System guide.

Absolutely. Devices are magnetically mounted and can be moved between locations in seconds. Simply update the DeviceID-to-location mapping in the API when you relocate a device. This makes Voodoo ideal for seasonal reconfiguration or temporary workflows.

Minimal. Most operators learn the system in under 15 minutes. The Device display tells them exactly what to do — which item, how many, and which direction. Color-coded LEDs provide additional visual cues. New hires can be productive on day one, which is one of the primary ROI drivers of pick-to-light systems.