> ## Documentation index
> Fetch the complete documentation index at: https://docs.predictefy.com/llms.txt
> Use it to discover every available page before exploring further.

# Smarkets

> The client-side trading lane for Smarkets, its credential doctrine, and the venue limits behind it.

## What you need first

- **Production status:** **Client-side only, by owner decision on 2026-08-18.** There is no hosted
  Smarkets execution lane and none is planned; `GET /v1/exec/venues` never lists Smarkets, and every
  `/v1/exec/smarkets/…` route answers `404 VENUE_NOT_SUPPORTED`. Trading runs through the
  venue-direct SDK client at `client.accounts.smarkets`.
- **Wallet and chain:** None. Smarkets is an off-chain fiat exchange; there is no signer, no chain,
  and no on-chain artifact anywhere in this lane.
- **Venue account:** Yes, and it must be **approved by Smarkets as an API user**. An ordinary
  account that has not been granted venue API access is rejected by Smarkets itself. That approval
  is granted by the venue, not by Predictefy.
- **Credentials:** Your Smarkets account **email and password**. They are sent only from your
  process directly to `api.smarkets.com` and **never transit Predictefy**. The session token they
  produce is held in volatile memory and is never logged, returned, persisted, or sent to
  Predictefy.
- **Funding:** The venue's own GBP card or bank rails. The funding registry records
  `fundingClass: fiat_custodied` with no collateral asset, no chain, and no hosted deposit helper.

## Why there is no hosted lane

This is a custody decision, not a missing integration.

Smarkets authenticates with a **full account login**. It publishes no scoped, revocable API key that
could be limited to order placement — the same credential that places an order can also read the
account and move money. A hosted lane would therefore mean relaying, to Predictefy's servers, a
credential that controls the caller's entire Smarkets account. That crosses the custody line this
platform does not cross: Predictefy holds no user funds and no user credentials, and the way it
keeps that promise is by never being on the path where an account credential travels.

So the credential doctrine here is stricter than on the hosted lanes, not looser. On a hosted lane
a transient venue credential passes through the execution service for exactly one request and is
then discarded. On Smarkets, nothing passes through at all.

A hosted lane remains a **future maybe** — if Smarkets ships scoped, revocable API credentials, the
objection above disappears and the decision can be revisited. It is not planned work today, and
nothing on this page should be read as a commitment to build it.

## The client-side write surface

```ts
import Predictefy from '@predictefy/sdk';

const client = new Predictefy({
  apiKey: process.env.PREDICTEFY_API_KEY,
  venueCredentials: {
    smarkets: {
      email: process.env.SMARKETS_EMAIL!,
      password: process.env.SMARKETS_PASSWORD!,
    },
  },
});

const order = await client.accounts.smarkets.createOrder({
  marketId: '...',
  outcomeId: '...',
  side: 'buy',
  amount: 5,
  type: 'limit',
  price: 0.5,
});

const cancelled = await client.accounts.smarkets.cancelOrder(order.id);
```

| Verb          | Venue call                                                         | Notes                                                                                                                          |
| ------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ |
| `createOrder` | `POST /v3/orders/`                                                 | `type: 'limit'` sends `good_til_halted`; `type: 'market'` sends an aggressive `immediate_or_cancel` limit at buy 9999 / sell 1 |
| `cancelOrder` | `DELETE /v3/orders/{id}/`, then a read-back of the cancelled order | Returns the venue's own post-cancel order state rather than an assumed one                                                     |

`amount` is **your own money at risk** — back stake on a buy, lay liability on a sell — not
Smarkets' `quantity` pot. At venue price `p`, the back stake is `quantity × p / 100,000,000` and the
lay liability is `quantity × (10,000 − p) / 100,000,000`. The client converts your `amount` into a
venue `quantity` and floors it, so the relevant contribution can never exceed what you asked for.

## Venue properties, not gaps

Three limits on this lane come from Smarkets and would not change if a hosted lane existed:

- **No modify.** Smarkets exposes no order-amend verb, so there is none to wrap. Cancel and replace.
- **MFA is unsupported.** This client does not accept MFA secrets, so a login that returns an MFA
  factor raises `NOT_SUPPORTED` rather than prompting. Use an account without MFA, or do not use
  this lane.
- **No WebSocket and no deep tape.** There is no Smarkets streaming lane. The public trades tape is
  real but hard-capped by the venue at **five fills per outcome**, and the venue accepts no tape
  parameters at all, so `limit` is applied locally and a window older than those five reachable
  fills returns fewer rows rather than a fabricated one. Public quotes are also delayed by the
  venue. See [Venue coverage](/reference/venues/).

`fetchPositions` is likewise unsupported: Smarkets publishes exposure but no positions resource, and
this lane does not derive one.

:::caution[Protect the login]
The email and password can access the entire Smarkets account, including withdrawals, and they exist
in your process for as long as the client does. Prefer a dedicated, restricted account, keep them
out of application logs, and rotate them if a process that held them is ever compromised. Venue and
jurisdiction eligibility remain the operator's and integrator's compliance responsibility.
:::