/my/ships Returning 500 error

[papaburgs]

Not sure when it started, but have not been able to use the /my/ships endpoint for the last 12 hours or so.

Other endpoints like /my/agent seem to work.

I get a 500 error with the response below

{
"error": {
"code": 3000,
"message": "The server did not return a valid response. If you want to help you can file an issue here: https://github.com/SpaceTradersAPI/api-docs.",
"requestId": "019a91c5-feb8-736e-8186-fd9d164ff18a"
}
}

I think something similar happened a couple weeks ago, but it was right before reset, and it was fine after that.

Issue is occurring in my code, manual curls and on the playground

[scumola]

I'm seeing this on one of my ships also:

[11:12:34] [INFO] [API] GET /my/ships/SCUM-5
[11:12:34] [ERROR] [API] Error: GET /my/ships/SCUM-5 - 500 Server Error: Internal Server Error for url: https://a
pi.spacetraders.io/v2/my/ships/SCUM-5
[11:12:34] [ERROR] [API] Response: {"error":{"code":3000,"message":"The server did not return a valid response. I
f you want to help you can file an issue here: https://github.com/SpaceTradersAPI/api-docs.","requestId":"019ae5a
1-737b-77
[11:12:34] [ERROR] [SCUM-5] Failed to get ship data: 500 Server Error: Internal Server Error for url: https://api
.spacetraders.io/v2/my/ships/SCUM-5
[11:12:34] [WARNING] [SCUM-5] Could not load ship data, retrying in 60s

Many of my other ships are returning valid data. The ships wasn't sold, so it should be returning correct data. Not sure why it's not returning data and getting a 500. Ran everything through AI and AI confirms that it should be valid and that the error is on the server side.

[15s] Credits: 55,112 (+0) | Mined: 0 | Sold: 0
SCUM-3: [████░░░░░░░░░░░] [██████████████░] 🪐 navigating to X1-YS22-AX5D
└─ 4x ICE_WATER
SCUM-4: [█████████░░░░░░] [███████████████] 🪐 planning route to X1-YS22-AX5D
└─ 2x SILICON_CRYSTALS, 3x ICE_WATER, 4x QUARTZ_SAND
SCUM-5: [???????????????] [???????????????] ⛏️ mining cycle 1
SCUM-6: [█████████░░░░░░] [███████████████] 🪐 planning route to X1-YS22-AX5D
└─ 2x QUARTZ_SAND, 3x ICE_WATER, 4x SILICON_CRYSTALS
SCUM-7: [████░░░░░░░░░░░] [███████████████] 🪐 planning route to X1-YS22-AX5D
└─ 1x QUARTZ_SAND, 3x ICE_WATER
SCUM-8: [█████████░░░░░░] [███████████████] 🪐 planning route to X1-YS22-AX5D
└─ 2x ICE_WATER, 2x SILICON_CRYSTALS, 5x QUARTZ_SAND
SCUM-9: [░░░░░░░░░░░░░░░] [███████████░░░░] ⛏️ extracting (0/15)
SCUM-A: [░░░░░░░░░░░░░░░] [███████████████] ⛏️ mining cycle 1
SCUM-B: [░░░░░░░░░░░░░░░] [███████████████] ⛏️ mining cycle 1
SCUM-C: [░░░░░░░░░░░░░░░] [███████████████] 🪐 planning route to X1-YS22-AX5D
SCUM-D: [█░░░░░░░░░░░░░░] [███████████████] ⛏️ extracting (1/15)
└─ 1x IRON_ORE
SCUM-E: [░░░░░░░░░░░░░░░] [███████████████] 🪐 planning route to X1-YS22-AX5D

New ships seem to be ok. It's like the SCUM-5 ship just disappeared from the server or something maybe? Was it destroyed by another player maybe? Shot down? :)

I also saw just /my/ships return a 500 around the same time:

[API] Error: The server did not return a valid response. If you want to help you can file an issue here: https://github.com/SpaceTradersAPI/api-docs.
[Sync] Error syncing ships: 500 Server Error: Internal Server Error for url: https://api.spacetraders.io/v2/my/ships?limit=20&page=1
Could not sync final status: 500 Server Error: Internal Server Error for url: https://api.spacetraders.io/v2/my/ships?limit=20&page=1

Both of these errors persist now.

[nouseforname]

SpaceTraders API – Ship Pagination Bug Report

Date: 2026-03-25
API Version: v2
Endpoint: GET /my/ships

---

Summary

The GET /my/ships endpoint exhibits inconsistent behavior depending on page and limit parameter combinations. Certain combinations return HTTP 500, making it impossible to retrieve all ships via standard pagination.

---

Observed Behavior

page	limit	Result
1	10	200 OK — returns ships 1–10
1	20	500 Internal Server Error
1	40	422 Unprocessable Entity
2	10	500 Internal Server Error
2	20	200 OK — returns ships 21–40
3	20	200 OK — returns ships 41–57

The meta field is missing from all successful responses (no total, page, or limit returned), making it impossible to know how many ships exist without iterating all pages.

---

Impact

• Ships in positions 11–20 (hex: 0xB–0x14) are unreachable via any working pagination combination.
• With 57 total ships, positions 11–20 can only be fetched via individual GET /my/ships/{symbol} calls — but only if the symbol is already known.
• One individual ship fetch also returns 500: GET /my/ships/NOUSEFORNAME-E (hex 0xE, position ~14).
• However, action endpoints on the same ship work correctly — POST /my/ships/NOUSEFORNAME-E/dock and POST /my/ships/NOUSEFORNAME-E/scrap both succeeded. The ship existed in the backend; only the read endpoint was broken.

---

Reproduction

# Works (first 10 only)
GET /my/ships?page=1&limit=10

# Fails with 500
GET /my/ships?page=1&limit=20
GET /my/ships?page=2&limit=10

# Works (skips positions 11-20)
GET /my/ships?page=2&limit=20
GET /my/ships?page=3&limit=20

Ships are numbered sequentially in hexadecimal (e.g. AGENTNAME-1 through AGENTNAME-39).
Positions 11–20 correspond to hex suffixes B, C, D, E, F, 10, 11, 12, 13, 14.

---

Workaround (client-side)

1. Fetch page=1, limit=10 → receives ships 1–10.
2. Fetch page=2+, limit=20 in a loop → receives ships 21–N.
3. Infer missing hex symbols (gap between last single-digit hex and first two-digit hex).
4. Fetch each missing ship individually via GET /my/ships/{symbol}.

This workaround is fragile, relies on knowledge of the hex numbering scheme, and fails for ships that individually return 500.

---

Expected Behavior

• GET /my/ships?page=1&limit=20 should return the first 20 ships with HTTP 200.
• All page/limit combinations within documented bounds should work consistently.
• The meta field should always be present and contain total, page, and limit.