Tack för genomtänkt input!
I detta fall är operationerna idempotenta, samma request hade genererat samma resultat även om de skickas igen, så det är imho inte det som är det "största" problemet i just detta scenario. Det är dessutom i detta scenario x antal dataposter som ska läggas till, men de har ingen relation sinsemellan, utan det är för att slippa göra flera hundra i stort sett identiska anrop, vilket hade ökat lasten både för dem och för oss.
Vi är medvetna om att 207 inte är en REST-responskod, men i avsaknad av tydlig best practice här (inte bara från DIGG, utan även på andra sajter så går rekommendationerna isär) så har vi valt denna väg. Givetvis informerar och dokumenterar vi att 207 kan returneras från denna endpoint. Det känns som en renare och enklare lösning istället att behöva loopa "x" antal gånger med full Request + Response-cykel för att göra något som enkelt kan utföras genom att skicka in en array av objekt. Ofta skickas data till oss efter det att datalager eller motsvarande har uppdaterats med någon nattlig körning och då blir det såhär våra kunder vill integrera med oss.
Anledningen till frågan här hos DIGG är att vi gärna vill följa myndighetens rekommendationer i möjligaste mån, men att vi här saknar tydlig vägledning.
Alternativet med 202 Accepted och då skicka med batch-id eller motsv. är helt klart en möjlig väg framåt 
, och då även mer korrekt enligt RESTful-principerna. Men även den har sina nackdelar imho då den kräver en extra request+responscykel, samt att det är oklart för API-konsumenten när de ska köra sin förfrågan för att kolla resultatet.
Tack igen för input, och andra får såklart också gärna komma med goda tankar och funderingar, vi lär ju inte vara de enda som stött på denna situation tänker jag. 
