Use the REST API when deployments should be repeatable
The REST API is the best SiteDropper surface for deployment scripts, CI jobs, internal tooling, or scheduled smoke tests. It follows the same path as the dashboard: create a project, upload a ZIP, analyze it, build it, deploy it, and return a live URL.
- Use REST for predictable automation where each step is controlled by your script.
- Use MCP when a coding agent should decide what to package and when to deploy.
- Use dashboard ZIP upload when a human wants the fastest manual path.
Step 1: log in and store the API token safely
Automation starts by logging in with an existing SiteDropper beta account and saving the returned JWT for later requests. Keep this token in your CI secret store or local environment, not in source control.
- Send your email and password to the login endpoint.
- Read the token from the response.
- Send Authorization: Bearer <token> on protected requests.
- Avoid printing the token in logs.
Step 2: package the app as a ZIP
Your script should create the same ZIP you would upload through the dashboard. For Node projects, run the local install and build before packaging so obvious errors fail before the upload step.
- Include source files, package metadata, static assets, and configuration needed to build or run the app.
- Exclude node_modules, caches, local build artifacts you do not intend to deploy, and secret files such as .env.
- If deploying built static output, ZIP the output directory instead of the entire source project.
Step 3: create the project and upload the ZIP
Create a SiteDropper project through the API, then upload the ZIP to that project. The upload response includes the version ID and an analysis operation ID. Save both values because later steps depend on them.
- Create projects with draft visibility by default for automated previews.
- Upload the archive as multipart form data using the file field.
- Store the project ID, version ID, and analysis operation ID in your script output or CI workspace.
Step 4: poll operations instead of guessing
Analysis, build, deploy, and deletion are asynchronous. Poll the operation endpoint until the status is succeeded or failed before starting the next step. This makes your automation more reliable than sleeping for a fixed amount of time.
- Poll analysis before reading the detected runtime and commands.
- Poll build before asking SiteDropper to deploy the build.
- Poll deploy before announcing the live URL.
- If an operation fails, print the error message and stop the deployment job.
Step 5: build, deploy, verify, and clean up
After analysis succeeds, queue a build for the version. After the build succeeds, queue a deployment for the build. Then verify the returned URL with a lightweight smoke check before sharing it or marking a CI job successful.
- Fetch build logs if the build fails so the script tells you what went wrong.
- Open or curl the live URL after deploy succeeds and look for an expected page marker.
- Keep preview deployments draft or private until your release process makes them public.
- Delete temporary smoke-test projects after verification so routes and runtime services do not linger.