What you can do in the dashboard

Everything the API does has a face in the dashboard, and a few things live only there: uploading a font, verifying a domain, reading a webhook’s delivery log, styling the embedded editor. These pages walk the left rail one item at a time.

​

The dashboard

The dashboard is the browser side of your SudoMock account. Sign in at sudomock.com; there is nothing to install and no second workspace to create. Any screen that spends credits shows the balance beside what the job in front of you will cost. The rail runs in the order the work usually runs: three items that make things, three that put them in front of somebody else, then the keys that let code work from outside. Settings, under Organization, decides who is in the team and what each person may touch. A new account starts on trial credits, so creating, saving and rendering work straight away: upload a Photoshop file and look at a finished image before you decide anything about billing.

​

Dashboard features

• Create a mockup from a Photoshop file, a product photo or a generated image, and save it as a template you render again later.
• Find, rename and delete what you saved, searching by name or by UUID, and upload several files at once.
• Upload the typefaces your text layers need and reuse one catalogue across the account.
• Register webhook endpoints, read every delivery attempt, then replay the ones that failed.
• Serve images from a domain you own, choose a default and bind it to a single key.
• Brand and constrain the editor your buyers see, then test it before embedding it in a storefront.
• Issue keys, watch them and revoke what leaked.
• Invite your team and pick each role, so everyone works against the same balance and keys.
• Read your plan, credit balance and invoices on the Billing page.

​

Choose your infrastructure

The Quickstart uploads a PSD and renders it in two calls. Its key comes from the API keys page and travels in the x-api-key header, which Authentication covers in full. With a template already saved, copy its UUID from the library and send it to the render endpoint. One account answers from every surface, so pick the one closest to your work:

• SDKs: render from Node or Python with a typed client that sets the header and parses the response.
• Integrations: drive a render from n8n, Make, Shopify, WooCommerce, Zapier, Airtable, Google Sheets or Adalo.
• API: call the endpoints directly over HTTP from any language.
• Agents: point an MCP client at the remote server and render inside a session.
• Rendering examples: copy a working handler for the framework you run.

Mixing them is normal: prepare a template in the browser, render it from a workflow builder while the shop is small, then move the same call into your own backend when the volume is worth it.

​

Manage your account from either side

The dashboard and the API read one account, one credit balance and one set of templates. A mockup uploaded in the browser renders over HTTP a second later under the same UUID, and one uploaded over HTTP appears in the library. Nothing is synchronised or re-registered, and everyone you invite sees the same library and spends from the same balance. Most of what the rail does has an endpoint behind it, so a job started by hand can be handed to code later: list mockups, render one, upload a font, register an endpoint, read its deliveries, open a Studio session and read the account behind the credit counter. Three jobs stay in the browser, because each changes what the whole account is allowed to do: verifying a custom domain, inviting somebody and setting their role, and everything on the Billing page.

​

Related guides