Add option to exclude attachments from inbound route

[odunayoogungbure-rgb]

resolves MSD-15032: Add option to exclude attachments from inbound route

I used AI to generate parts of this PR

Yes

Changelist

• Accept include_attachments on inbound routes
• Return include_attachments on inbound routes
• Document the option in the README

Risks

The builder body holds a boxed Boolean, not a primitive, so an unset flag is omitted by Gson rather than sent as false. A primitive there would silently drop attachments on every update that did not set it — worst case, routes quietly stop forwarding attachments. Scenario 4 is the one that catches this.

Performance impact

None

Security impact

None

How to QA

(API only — no UI) — this is a Java SDK. QA is the test suite plus a short program against a branch env.

This cannot be fully QA'd until the API change for MSD-15032 is deployed. Against current production the key is ignored, so scenario 3 will show the field absent. Point the client at a branch env with the API change before QAing scenarios 3 and 4.

Scenario 1 — the recorded test suite still passes

• Setup: none beyond a checkout of the branch.
• Steps: run mvn test -Dtest=InboundRoutesTest (via Docker if you have no local maven).
• Expect: all inbound route tests pass against the recorded fixtures. The fixtures were hand-edited, not regenerated: VcrTape keys each response by sha1 of the request url, method and body, and no inbound test sets this field, so the request hashes are unchanged — only the recorded response values were renamed to "include_attachments": true.
• If broken: a test tries to reach the network and fails with a 401, which would mean a request hash stopped matching a fixture key.

Scenario 2 — existing calls are unaffected

• Setup: an account with a verified domain that can hold an inbound route.
• Steps: create a route with the README's "Create an inbound route" example as it read before this change, without calling includeAttachments().
• Expect: the route is created, same as on main. No 422.
• If broken: a 422 naming include_attachments.

Scenario 3 — the flag round-trips

• Setup: as above, against a branch env with the API change.
• Steps: build a route with .includeAttachments(false).addRoute(), then fetch it with ms.inboundRoutes().getRoute(id).
• Expect: route.includeAttachments is false on both the add response and the fetch. Creating without the call gives true.
• If broken: the field stays true after being set to false, which means the @SerializedName is not matching.

Scenario 4 — omitting on update preserves the value

• Setup: the route from scenario 3, with the flag false.
• Steps: call .updateRoute(id) with a changed name and includeAttachments() never called. Then fetch the route.
• Expect: the name changed and includeAttachments is still false. Calling .includeAttachments(true) then flips it back.
• If broken: the flag resets to true after an update that never mentioned it.

Does not need QA: getRoutes, getRoute and deleteRoute on their own (unchanged), the SMS inbound route classes (separate package, untouched), and every other part of the SDK.

How to release

Standard release — but not before the API change for MSD-15032 is live in production. Publish to Maven Central as usual once it is.

Screenshots, recordings

N/A

🤖 Generated with Claude Code