Add POST Endpoints to Accept or Reject Contracts via ESI
Feature Request
I think it would be nice if we could accept or reject contracts through the API. Not create new ones — only accept or reject existing contracts that are already assigned to the character or corporation.
Use case
Third-party tools already allow us to view both personal and corporation contracts, but players who operate multiple characters or help manage corporation logistics often run into a workflow problem:
To keep activity flowing, they must frequently dock up, stop what they’re doing, log over to the relevant character, accept a contract, switch back, and undock again.
For players running several characters, or those coordinating corp-level industrial, hauling, or market operations, this becomes very tedious and breaks gameplay flow.
Allowing acceptance/rejection through ESI would make contract management much smoother while still requiring explicit user authorization, making it both convenient, secure, and manual.
Authentication
Existing scopes already allow read access to character and corporation contracts. The accept/reject functionality would only require a corresponding POST action using those existing scopes, with no new ones needed (unless CCP prefers more granular scopes).
Example return
Propose what an example return might look like. E.g.:
[
{
"contract_id": 1234567,
"character_id": 93550321,
"status": "accepted",
"message": "Contract successfully accepted."
}
]
[
{
"contract_id": 1234567,
"character_id": 93550321,
"status": "rejected",
"message": "Contract successfully rejected."
}
]
Checklist
Check all boxes that apply to this issue:
- [x] Feature request description is provided
- [x] Use case exists
- [ ] Feature requires a new route
- [x] Feature adds data to existing route
- [ ] Feature requires new auth scope
- [x] Feature can reuse existing scope
- [ ] Feature does not require auth
- [ ] Meta feature, applies to all routes
I can't see this happening. It would be too easy to mix this scope in with a long list of other scopes (think apps like AllianceAuth).
Then, a nefarious party could just start making contracts to empty wallets and known assets, of which this scope could allow them to auto-accept.
If a person is going to get "scammed", at least give them the respect to be logged into the game when it happens.
It may not be a good idea that allow user operate stuff about "money" and "skill" through api.