splitwise / api-docs

API documentation for the Splitwise API.
http://dev.splitwise.com
28 stars 16 forks source link

Zero people involved error while creating expense #68

Closed joylazari closed 1 year ago

joylazari commented 1 year ago

Hi there, and thanks for the awesome work you've done with this API!

I'm building a script to import past, settled, expenses from a CSV file produced by the soon-to-be-defunct danish WeShare.

While some of the expenses are created without errors, some others fail with the message: "There are zero people involved in this expense! Make sure to add some before saving.", and can't seem to find any reason for that, as the users' info and shares are correctly passed in the request.

An example of a failing request is the following:

curl -X POST \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer ***" \
    -d '{
        "cost": 385,
        "description": "failing expense",
        "date": "2023-01-13T12:48:56.000Z",
        "group_id": ***,
        "users__0__user_id": ***,
        "users__0__paid_share": 192.5,
        "users__0__owed_share": 192.5,
        "users__1__user_id": ***,
        "users__1__paid_share": 192.5,
        "users__1__owed_share": 192.5,
    }' https://secure.splitwise.com/api/v3.0/create_expense

JSON response:

{
  "expenses": [],
  "errors": {
    "base": [
      "There are zero people involved in this expense! Make sure to add some before saving."
    ]
  }
}

This other example, though, goes through without errors:

curl -X POST \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer ***" \
    -d '{
        "cost": 56,
        "description": "successful expense",
        "date": "2023-01-15T14:29:10.000Z",
        "repeat_interval": "never",
        "currency_code": "DKK",
        "category_id": 18,
        "group_id": ***,
        "users__0__user_id": ***,
        "users__0__paid_share": 28,
        "users__0__owed_share": 28,
        "users__1__user_id": ***,
        "users__1__paid_share": 28,
        "users__1__owed_share": 28,
    }' https://secure.splitwise.com/api/v3.0/create_expense

JSON response:

{
  "expenses": [
    {...}
  ],
  "errors": {}
}

Any ideas why?

Thanks (:

joylazari commented 1 year ago

Another example. This time I tried to also send a calculated net_balance but to no avail. I left the x-request-id in clear if you guys want to dig into your logs (:

> POST https://secure.splitwise.com/api/v3.0/create_expense
> Accept: application/json; charset=utf-8
> Content-Type: application/json; charset=utf-8
> Authorization: Bearer  ***,
> {
>     "cost": 371.81,
>     "description": "***",
>     "date": "2021-09-13T16:25:46.000Z",
>     "created_at": "2021-09-13T16:25:46.000Z",
>     "repeat_interval": "never",
>     "currency_code": "DKK",
>     "category_id": 18,
>     "group_id": ***,
>     "users__0__user_id":  ***,,
>     "users__0__paid_share": 371.81,
>     "users__0__owed_share": 185.91,
>     "users__0__net_balance": 185.9,
>     "users__1__user_id":  ***,,
>     "users__1__paid_share": 0,
>     "users__1__owed_share": 185.9,
>     "users__1__net_balance": -185.9
> }

< 200 OK
< connection: keep-alive
< server: nginx
< date: Thu, 26 Jan 2023 14:12:55 GMT
< content-type: application/json; charset=utf-8
< transfer-encoding: chunked
< vary: Accept-Encoding, Accept
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
< x-download-options: noopen
< x-permitted-cross-domain-policies: none
< referrer-policy: origin
< content-disposition: inline; filename="response.json"
< cache-control: no-store
< pragma: no-cache
< expires: Fri, 01 Jan 1990 00:00:00 GMT
< etag: W/"40da2df7d610b0c118b9d16336b77d97"
< x-request-id: 3a8744cc-c324-4cf2-b20b-006794de6211
< x-runtime: 0.030467
< strict-transport-security: max-age=63072000
< via: 1.1 vegur
< {
<     "expenses": [],
<     "errors": {
<         "base": [
<             "There are zero people involved in this expense! Make sure to add some before saving."
<         ]
<     }
< }
mgod commented 1 year ago

Sorry for the slow response here. At a quick glance here, I suspect the issue is that you are submitting the amounts as numbers instead of strings. Should be "371.81" not 371.81 in the parameters. net_balance should not be included in the shares. We do this to avoid floating point precision issues in various JSON parsers.